On a serious note. Keeping up with changes in the Javascript community seems like a full time job. I don’t know how they get any work done.
The major frameworks of today were already well established then, and the last really big update to the language in 2015 had already been in fairly wide spread use via transpilers (traceur and later 6to5, which became babel).
Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much.
Rust appeared 7 years ago. Rust did not went through any churn. Arguably, the first iteration hasn't even ended yet.
They really aren't. Editions are just a mechanism to allow Rust developers to push backwards-incompatible changes as opt-in features. I repeat, Rust hasn't even went through its first iteration, and it shows a fundamental lack of understanding and insight to argue otherwise.
The backend was written in Go; everything could be updated to the latest version without any incompatibilities at all.
People having been complaining about incompatibilities in Rust too, but Rust is a much newer language, and I think things have settled by now as well. I don't know much about C#.
I'm not saying the problem doesn't exist, or that's certain parts of the ecosystem haven't experienced more churn than others. I am saying that "js churn" has been a meme joke for a long time, and has been old for almost as long.
I'm not so sure about that; things haven't really changed that much. A language gaining new features doesn't typically break everything, even when libraries start adopting them.
But even if it does: sure, languages can have their "everything changed" watershed moments, but no such watershed happened in JS in the last few years, yet updating things is still a lot of effort, and a bit of a pain.
It actually has nothing to do with the language; it's just the mindset. For whatever reason compatibility is just not high on the list of priorities in the JS ecosystem. I maintain Go packages that have been compatible for over 10 years; I make special effort to ensure they remain compatible, and even if a compatibility break is required I try to minimize it. There is nothing in JS or npm preventing the same kind of mindset.
Either way, it's not a "meme joke" and it's certainly not "old" as the problems still exist today. If you (or someone else) would say "I think the advantages of moving faster are more important than remaining compatible": okay, fair enough; I can see that's a reasonable point of view, even though I personally don't agree with it. What I always find off-putting is the casual dismissal of the problems. The Python 3 transition could have been handled better and dependency management remains a bit of a mess in Python: I don't see many Python developers deny these are (or were) real problems.