Hacker News Reader

Comment by matwood | Hacker News Reader

JS in general moves fast and packages range from great to WTF in quality. I would suggest using Babel(or something similar) for all future JS development. That way you can use ES2015/2016 features now and have them work in most environments.

I have a built a small API using express and passport and so far these node changes have not impacted my code.

Another option for fast API development is Java 8 with SpringBoot and Jetty. People hate on Java and Spring, but the latest versions of both are very powerful and easy to get going. If you end up needing more it is there.

View on HN

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

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?

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.

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.

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.

Babel does some other magic that you might not realize, such as converting anonymous functions to named functions (and then assigning those to a variable of the same name).

It has some magic, but we already have to use polyfills to support multiple browser versions. I see something like Babel as the global polyfill of the future. Use latest es features now and have them go native over time.

Reply on news.ycombinator.com