Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.
On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version.
But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem.
(Then there are arguments about statically bundling libc / VCRUNTIME, etc.)
It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).
Once a transpile step is required, it doesn't make as much of a difference what is on the other side.
FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.
Talk about naming problems / sorting problems. They've adopted Microsofts versioning system where Windows 8 is newer than both Windows 98 and Windows 2000.
Does anyone remember the Y2K problem. Anyone?????
They worked out naming things properly (where computers are involved) was a big problem in the 1960's. But we still only allocated 3 bytes for the version of C or something...?
If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all.
Comparing C spec updates and JS spec updates is comparing apples to oranges.
I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.
