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.

Word of caution on how we tend to reason about complex systems. They don't form a chain but a web, and that changes everything to understand how they can break.

Good reminder that the raw UNIX timestamps have interesting properties and often are enough not necessarily needing to rely on something more complex. Also gives nice criteria for picking between said timestamps and higher level types.

Interesting statistics, this show how important it is to have well structured and focused change sets as much as possible.

Things could indeed be more convenient... if this was the case we'd probably have less security breaches. Making super complex tools and then complaining that people are holding them wrong isn't gonna help.

Another testament to the fact that it's probably better to have minimal dependencies on your webpages. This is especially true for documents if you're aiming for longevity. If you're making an actual application the trade-off will be different.

Mind how you pick your dependencies and how they fare over time. You might need to reevaluate and let go some of them.

Maybe you don't need to pull even more dependencies. Think of the operational costs and the complexity.

Good reasoning, multi-page applications should be the default choice for web frontends architecture. The single page applications come at a cost.

Looks like the morbid fascination for microservices is fading. This is very welcome. This piece is a good criticism of this particular fad and gives an interesting theory of why it came to be.

It's clearly not clear cut, it's a whole spectrum. I wish more web developers would at least ask themselves the question before having knee-jerk reactions reaching for their favorite framework of the day.

Nice reasoning. It very well highlights the tradeoffs coming the choice they made. And of course the decision might change if the situation changes.

To take with a pinch of salt, it conflates a few things in my opinion. Still it's a good reminder that eliminating complexity shouldn't be a goal. Managing said complexity and avoiding the undue one, this is what matters.

Excellent points. Don't be fooled by alluring architecture changes. Always keep the complexity in check and favor tuning what's already here or changing your use patterns to meet the performance you need.

Hosting applications can be cheap and simple. You need to cater to complexity and mind your dependencies.

A bit sarcastic, but makes its point efficiently. It's important to realize that more code to maintain is definitely not what we need.