> 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.
If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.
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.
> If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.
Right, but if the developer transpiles their source code and distributes it then the JS end-user is in the same situation as the C binary user. Distributing ES6 code without transpiling it is akin to distributing C source code without compiling: the end-user would need to have an up to date compiler/runtime to execute the code.
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.