3 ms·

On a technical level, you're absolutely right, JS as a language has an amazing amount of backwards compatibility. So much that IE running on Win XP can run thin

On a technical level, you're absolutely right, JS as a language has an amazing amount of backwards compatibility. So much that IE running on Win XP can run things that Babel compiles from ECMAScript X in 2020. But, the ecosystem is really something different entirely, and this isn't meant to be a slight to JS at all. It's just reality when running production code in 2020. Python's standard library is comprehensive, well-maintained and well-documented throughout. JS, by comparison, relies on packages from npm for the same features. Which means the issue my org has with the JS ecosystem is the stuff that's not built into the language spec or otherwise maintained by a central body, not that the things built into the language isn't standing the test of time or something like that. I hope that explains things.

robocat 6y ago
> But, the ecosystem is really something different entirely Most of the ecosystem changes are driven by externalities - web-servers, browsers, developers. You can still choose to use an old web framework and it will work on modern browsers. That is entirely different from the Python 2.x -> 3.x change. The days of a simple CRUD web page delivered by a server are long gone. jQuery is still brilliant at adding adornment to HTML produced on a server. Putting your view and controller into JavaScript just makes sense. SPAs need completely different frameworks to support the highly complex needs of client-side rendering and interaction. Ten years ago component based renderers were not common and developer-friendly syntax hardly existed. Frameworks are being pushed by the needs of huge systems (Facebook), server side pre-rendering, and partial updates (correct term? to improve first load and responsiveness). Also the features available in a modern browser are radically different. Remember building up a string of HTML in JS for performance reasons? Avoiding the DOM because it was slow? So many features only started becoming reliable or available around Internet Explorer 11, yet now IE11 is hardly ever supported because it is missing critical features. An example is that in older Internet Explorer and Safari, you could theoretically update CSS rulesets from the DOM, but in practice doing anything dynamic risked crashes and memory leaks (even loading new CSS pages was difficult and error prone and browser specific e.g. detecting CSS load failures). Note: I was supporting the same JavaScript codebase for over a decade (initially IE5.5). There were no breaking changes in the ECMAScript, and very very few in the DOM (mostly driven by dropping IE specific DOM). The changes in the codebase were mostly driven by wanting to support new features in browsers.

robocat 6y ago

> But, the ecosystem is really something different entirely Most of the ecosystem changes are driven by externalities - web-servers, browsers, developers. You can still choose to use an old web framework and it will work on modern browsers. That is entirely different from the Python 2.x -> 3.x change. The days of a simple CRUD web page delivered by a server are long gone. jQuery is still brilliant at adding adornment to HTML produced on a server. Putting your view and controller into JavaScript just makes sense. SPAs need completely different frameworks to support the highly complex needs of client-side rendering and interaction. Ten years ago component based renderers were not common and developer-friendly syntax hardly existed. Frameworks are being pushed by the needs of huge systems (Facebook), server side pre-rendering, and partial updates (correct term? to improve first load and responsiveness). Also the features available in a modern browser are radically different. Remember building up a string of HTML in JS for performance reasons? Avoiding the DOM because it was slow? So many features only started becoming reliable or available around Internet Explorer 11, yet now IE11 is hardly ever supported because it is missing critical features. An example is that in older Internet Explorer and Safari, you could theoretically update CSS rulesets from the DOM, but in practice doing anything dynamic risked crashes and memory leaks (even loading new CSS pages was difficult and error prone and browser specific e.g. detecting CSS load failures). Note: I was supporting the same JavaScript codebase for over a decade (initially IE5.5). There were no breaking changes in the ECMAScript, and very very few in the DOM (mostly driven by dropping IE specific DOM). The changes in the codebase were mostly driven by wanting to support new features in browsers.