Excellent point, we made the web too complex for regular users. This is actually an issue in term of access and democracy for people to write content there.

A good list to design HTML forms. The bar is indeed high and there's value in simplicity.

Or why anticipating too much is merely a gamble. You can be lucky, but how often will you be? Also I agree that in such cases the performance will be impacted longer term leading to a death by thousands of paper cuts.

Definitely not as fashionable as the kubernetes craze. This gives very interesting properties that multi-tenant applications can't really provide. The article is nice as it lays out properly the pros and cons, helps make the choice depending on the context.

Interesting musing about the "software crisis" which was declared in the late 60s. We're coping with it by piling levels of abstractions but clearly we're still not out of it. Our craft still needs to grow.

Nice return on experience of using a simple stack to serve loads of web requests.

It might not look like a lot from the outside, but "just implementation details" in fact hides quite some work and complexity.

Very nice piece about the various types of complexities we encounter in our trade, and what we can or should do about it.

Some problems are indeed tackled faster by having a simulation allowing to explore potential solutions. It's tempting to go very formal and theoretical but it'd require more effort and be more error prone.

Shows well why you likely don't want to use GraphQL. The chances you need the extra complexity and caveats are very slim.

Since this particular fad apparently doesn't want to die... this is a good reminder about why you want to do something simpler.

Definitely this. We tend to like complexity too much as a profession and field. It's also a good reminder that the complexity of the problem and the complexity of the solution shouldn't be conflated.

Keep things as simple as possible, they might turn out to be robust too.

With some tuning SQLite can go a long way, even for server type workloads. There are still a few caveats but in some case this can reduce complexity and cost quite a bit.

This is about a Rust library but equally applies to any ecosystem which allows to easily pull a dependency. As soon as you pull them, you need to monitor their health for the sake of your own project.

When guidelines contradict each other. You need a proper way to communicate where a piece of code stands.

Interesting how feeling stupid can actually push you toward good engineering practices, isn't it?

Interesting thinking about constraints and their rough classification as restrictive or enabling. I also liked how they're tied to complexity.

Definitely this, mind the complexity you introduce in your code. Looking smart is not the goal here...

Nice ode to simplifying web projects, to great effects. You can go a long way serving millions of requests if you choose your tools properly.