No, the web people have it wrong. It's called:

- Failure to do upfront design (yay, misinterpreted agile/MVP/etc)

- Reinventing wheels over, and over, and over

Newer versions and frameworks tend to be 10% improvement, and 90% unnecessary churn.

I'd say PHP is still getting a lot of good and important improvements

PHP exactly makes my point.

PHP was a no-good, terrible, poorly-made, horrific original design for something like powering Facebook. As a result, it needed a lot of good and important improvements.

Or to be more specific, it was a great design for what it was intended to be: a pet hobby project to make it easier to make Personal Home Pages, and was never intended to be a programming language.

https://en.wikipedia.org/wiki/PHP#Early_history

The concept of putting out something this bad, and then refactoring for over a quarter-century to make it almost-usable, is exactly the definition of the webdev way.

The result is a ton of churn.

And we've been making the same "mistakes" with JS too!

But if PHP and JS are so shit and full of churn, why are they so popular and widely used? And have been used to build larger, globally successful projects?

With JS, the answer is because Netscape adopted it, and it had market share. If you wanted to code which ran in web browsers, you needed to use it. Netscape, the company, no longer exists, so I wouldn't call it all too successful an outcome. From there, momentum.

Early history is in '95, Netscape hired Brendan Eich to embed Lisp in Netscape, while simultaneously pursuing a partnership with Sun to embed Java. Sometime that year, Lisp changed into a new language, which was created and shipped in beta, by September 1995. We're talking a few months.

If we had designed a sane framework upfront -- even 6 more months design time -- the web would likely be a decade or two ahead right now.

Most of the early "improvements" to JavaScript were stop-gaps created under similar cultures, which would need to be replaced again and again. It's not that we didn't know how to make a decent programming language in 1995; it's that we didn't.

Today, I do about half of my coding in JavaScript since it runs in the browser, and therefore on all platforms. It has nothing to do with the painfully bad language design.

> the web would likely be a decade or two ahead right now

Seeing how the trajectory of web development seems to be "pile on more and more complexity, most of it unnecessary", I'm not sure if I'm supposed to be sad or happy about this.

Because they were in the right place at the right time. JS just happened to be the first web scripting language. And PHP competed against gems such as ASP (pre-.NET) and ColdFusion at the time when server-side web development was exploding.

That’s because our industry is not making choices based on merit, it makes them based on fashion.

sure, I won't disagree with that, my point was more that the updates are more than 10% useful features usually. You can definitely make a point about how long it took php to get its type system into shape, but php is not exactly just some trendy framework of the week, and there are valid reasons to pick php as your language of choice (namely that it's the lowest barrier language especially for having non technical people do their own installation on some random server/shared hosting)

Seen locally, all improvements are useful. PHP is better each year.

Seen globally, it's 10% improvement and 90% churn. One "improvement" is a half-fix, another is another half-fix, and so on, where after 5 improvements you're 97% of the way there.

In the meantime, you've broken backwards-compatibility five times, perhaps not always in the literal sense (old code still runs), but in the practical sense (old code has to be rewritten to follow modern conventions and be compatible with new code).

You've also had five learning curves.

And you have a ton of legacy stuff to support, from each of those five changes, leading to an almost unbounded explosion of complexity.

PHP and PostgreSQL get a big release every year with good improvements. That you have to wait for the next stable release of debian (or in this case the one after this because they did not upgrade to the newest one) is not a failure of the web people! We are talking about one release every year, not every few weeks! Getting them years later just shows how unrealistic sometimes these stable distros are.

> We are talking about one release every year, not every few weeks! Getting them years later just shows how unrealistic sometimes these stable distros are.

* https://deb.sury.org

* https://wiki.postgresql.org/wiki/Apt

There are times when I want slow movement, and times when I want fast movement. Debian allows for both.

Sure you can use external repositories. But why bundle old packages when everyone then has to use external repositories to not get really old versions?

Testing for one:

* QA to make sure all the interdependencies aline correctly

* making sure the upgrade process runs smoothly, and that going from version X to version Y of some package is well-tested

It also depends on the upstream release cycle of the software package. The distro may wish to use the LTS version software (e.g., OpenJDK, OpenZFS, Django, Zabbix) but developers may wish to be more bleeding edge for new functionality.

Static binaries like Snap, macOS, etc. solve “moving slowly” issue. There should be little need to update the core OS (kernel, initd, /etc stuff) often.

It is possible that if you build up a routine to always stick to the latest, it will become an automatism. This opens the door to several types of risks.

Containers are always an option.