3 ms·

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, especi

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?

bonif 11y ago
>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.
- s_kilk 11y ago
  Pretty much. It's not like we're stuck for options.
- matwood 11y ago
  I would agree and why I brought up java 8 and SpringBoot above.
csvan 11y ago
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.
coldtea 11y ago
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).
bmn_ 11y ago
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.

bonif 11y ago

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

s_kilk 11y ago
Pretty much. It's not like we're stuck for options.
matwood 11y ago
I would agree and why I brought up java 8 and SpringBoot above.

csvan 11y ago

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.

coldtea 11y ago

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

bmn_ 11y ago

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.