Why this urge to keep up to the latest and greatest? Especially for a transpiler? If it is converting your code just fine, why update?

Probably the concern that waiting between updates means that if you are forced to update for some reason (critical bug or must-have feature) you have a tougher upgrade path.

Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.

Node.js modules: from brand new to "unsupported legacy hell" in "a year or two."

There's no way this is sustainable, but I'm at a loss of how to fix it, especially when the ECMAScript language itself is evolving at such a rapid pace. Any ideas?

It's a cultural thing.

JS being relatively fashionable and easy to write, it attracts all the younger devs that can't be bothered with backwards compatibility, stability, etc, and keep changing, restructuring etc their projects as they go along.

There are exceptions of course, e.g. anything by jashkenas, but this breakage happens a lot. Also with people adopting the latest shiny new framework every year or so (e.g. it feels like ages when Backbone was the shiny new thing, but it was merely 5 years ago -- since then we've had Ember, then Angular, then React take the spotlight).

Rapid pace is fine because the language spec is backward compatible. The module problem is rather mostly on the API level. To fix:

• On the technical side, needs the equivalent of CPAN testers to automatically show where stuff breaks.

• On the social side, needs the fostering of a culture where breakage is considered ill-mannered, and module maintainers hence go to lengths to prevent it or fix it promptly.

>but I'm at a loss of how to fix it, especially when the >ECMAScript language itself is evolving at such a rapid pace. >Any ideas?

Avoid Javascript on the server, problem fixed.

Pretty much. It's not like we're stuck for options.

I would agree and why I brought up java 8 and SpringBoot above.

There were 6 years between ES 5 and 6, and it will most likely be another 1-2 years before we have complete, well tested ES6 coverage across all major browsers. ES6 is fully backwards-compatible with ES5 anyway, so it's not even a Python-kind of language evolution.

In the case of Babel - performance. Even with all the fantastic work that has been done on it so far, good luck avoiding massive transpile times for non-trivial ES6 code bases. I imagine TypeScripts (and other) transpilers have the same issue.

In a project with over 600 required js files, 25kloc in project, way, way more from npm: the whole compile takes around 25s.

An incremental compile takes ~1-2s.