5 ms·

But then you have to keep up with Babel changes too... http://babeljs.io/blog/2015/10/29/6.0.0/ http://babeljs.io/blog/2015/10/29/6.0.0/

merpnderp 11y ago
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?
- Goronmon 11y ago
  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.
- coldtea 11y ago
  Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.
  - callahad 11y ago
    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.
  - deleted 11y ago
    [deleted]
- csvan 11y ago
  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.
  - 15155 11y ago
    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.

merpnderp 11y ago

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?

Goronmon 11y ago
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.
coldtea 11y ago
Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.
- callahad 11y ago
  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.
- deleted 11y ago
  [deleted]
csvan 11y ago
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.
- 15155 11y ago
  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.