I wonder if there's something about changing uses cases. If you design for x and y use cases then you end up with a nice, simple design for x and y. People then start doing a lot of z so you adapt to support z, but it adds some complexity because it's not exactly what you had in mind when you laid the foundations.

A competitor comes along who's designed for y + z, and everyone loves how nice and simple it is. Then use case u comes along...

If we are to trust a certain philosophy based on simplicity, one of the _very hard_ things you have to do as a head maintainer of software is to have the ability to say no when that case arises.

That’s the trick - sometimes, if you don’t add the features, you lose share because the market has shifted and now a different set of features are what is valued. So you can either patch and lose focus, or not patch and lose customers.

Nah, probably use case x. Rinse repeat.

>I'm old enough to remember the same complaints about Apache, and nginx being the simpler alternative.

Was about to comment the same !

What is that saying:

"You either die early, or live long enough to see yourself become the villain" ?

Having used Apache, Caddy, Nginx and more, I can tell you it't not about "sophistication" or features necessitating complexity.

It's about bad configuration file design, little thought put to usabillity and ergonomics, and, actually, a total lack of knowledge in that domains (usability) on behalf of the devs...

If you look at those three specific examples, you'll see decades of progress in the field between them. I don't think it's fair to say bad config file design, but maybe more fair to say that we've just gotten better at it as an industry over the last 30 years, and the ability to write better config files has gotten easier as well.

This seems very much like the browser/frontend space, where Webpack was once cool and slim, but is now just as bloated and slow as the systems it set out to replace.

Was Webpack ever slim? I always used browserify when I wanted a slim option.

glad someone mentioned it, browserify is way simpler to use and bundle. But now we have esBuild!

Webpack was never slim. It just integrated things nicely in a more declarative way than Grunt/Gulp.

> Something about systems evolving to a level of complexity/sophistication until they collapse under its own weight...

To my knowledge the nginx config hasn't gotten more complex.

I don't know caddy but I suspect it's just simpler.

Yeah, what's happened here is that Caddy is optimized for the most common use cases and gives them a "happy path." This simplicity is only possible in a world where something like nginx (and apache httpd before it) exists and people can figure out what the "happy path" should even be.

I’m old enough to remember Nginx and it’s selling point was never easy of configuration. It was always about the number of connections it could handle which made it great as a reverse proxy for web2.0

> I'm old enough to remember the same complaints about Apache, and nginx being the simpler alternative.

Nginx is still far simpler than Apache.

It just so happens that subsequent projects picked specific usecases to work on their happy paths to make them far simpler. Certificates is one of them.

> Something about systems evolving to a level of complexity/sophistication until they collapse under its own weight...

This is nothing of the sort. It's a matter of newer and better options popping up, not that old options got worse.

I came fro Apache through Nginx to Traefik and shortly tried Caddy. Went back to nginx for a lot of stuff because it's easier to understand and debug than Traefik.

I think a shell script with certbot and "nginx reload" is much easier than some closed service I can't take a look at.