Comment by robocat | Hacker News Reader

Comment by robocat | Hacker News Reader

Parent Full thread

> and none of the headaches that, say the JS ecosystem gives.

ECMAScript is the language, and it is amazingly backwards compatible back 20 years to about the start of the century without any trouble, and plenty of tooling like TypeScript can target ECMAScript 3 released a score of years ago.

Python could have added a ‘use strict’; in 3.0 to avoid a breaking change!?

Sure, since then browser features have radically changed and frameworks have changed, but the language itself has been extremely solid. Conflating JS and the ecosystem is not a fair comparison.

Also there have been many competing different implementations of JS engines, with amazing levels of compatibility between them (even Internet Explorer 5.5 released 2000 only had a few very minor known quibbles in the ECMAScript implementation).

Edit: Of course Unicode is actually hard to deal with because ECMAScript uses UTF16 for strings and symbols, even though the source code is usually written in UTF8. And note that the u flag was added to RegExp expressions to deal with Unicode better in ES2015 (especially U+10000 and greater, which are generally difficult to deal with in ECMAScript code).

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.

> 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.

Reply on news.ycombinator.com