Earlier quoted context omitted.
If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doe…
> 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. 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.
The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse.
All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.