Comment by _greim_
11 years ago
I suspect there will be a split in the npm ecosystem now, not so much along node/iojs lines but along es5/es6 lines. There's already been lots of discussion about whether module builders should publish es6 code, or should everything be transpiled down to es5 code in order to keep the ecosystem unified (the unspoken caveat being, around es5).
I think es5 is a dinosaur as of today, so I say go ahead and publish es6 code, and if you want to be nice to es5 people then add a prepublish transpiler that makes something like this possible:
// es6 people can do
var foo = require('foo');
// es5 people can do
var foo = require('foo/es5');
Important to note: because JavaScript itself is always backwards-compatible (1JS), any code that runs on Node will run on iojs, but not necessarily vice versa.
That means there need not be a split in the ecosystem: people who want maximal coverage can target ES5, while people who want the latest features can target ES6. Unlike the browser, however, where people can't control their runtimes, I suspect there will be much less tolerance for sticking with older versions of JavaScript.
Indeed, the pain and suffering people have felt with IE6 will likely make everyone much more willing to reject an unnecessary lowest-common-denominator approach on the server. We're liberated on the server. Let's act like it.
> We're liberated on the server.
I'm liberated on the server in my own app, but not necessarily if I'm publishing something for everyone to use. In that case I'm either forced to feature-detect my way along, or target certain engines. The reason I think the latter will happen is devs to whom node was an escape-hatch from client-side hell will loathe the idea of going back. E.g. [1]
[1] https://twitter.com/brianleroux/status/554753200503271424
> Important to note: because JavaScript itself is always backwards-compatible (1JS), any code that runs on Node will run on iojs, but not necessarily vice versa.
Though I'd imagine this will not hold true with addons, seeing as there are vastly different versions of the V8 engine.
I'm not sure it's worth publishing both ES6 and ES5 transpiled versions when you could just glue the transpiler into Node's "require": http://6to5.org/docs/setup/#require-hook
Please don't rely on require hooks in libraries. They are kind of evil in applications already (because they amplify the "synchronous require" problem). Test your library against a version of 6to5, compile, publish, and remove that paragraph in font size 48 from your README.*
(*) I hope you add such a paragraph when your library relies on a global require hook that changes the default behavior of require for all .js files in all libraries.
What is 'the "synchronous require" problem'?
I've never run into issues with the CoffeeScript require hook, for example.
5 replies →
> es5 is a dinosaur as of today
I don't think so. People publishing libraries in ES6 are asking for trouble. There are far too many half-complete ES6 implementations out there and compiling to ES5 definitely is the way to go (for libraries) unless there's a really compelling reason not to.
It looks like iojs is only going to ship features once they've shipped in Chrome without a flag. The compelling reason to use the features is that they're useful!
EDIT: I don't think anyone is going to be sympathetic to holding back from using conveniences because people are choosing to stick with an old runtime. It's a different ballgame than the browser.
I would make a strong cut between "application code" and "library code". For the former compilation to ES5 is overkill because the author of the code controls the runtime. For the latter the library either has to contain a long list of "tested with the following versions of the following runtimes and with the following versions of the following ES6-to-ES5-compilers" or it should be compiled pre-publish into a format with known semantics.
Example: I wanted to use the WHATWG streams code. But then I realized that they used an ES6 subset that is currently only compatible with traceur. The result: I had the choice between patching the code or downloading traceur, compiling the library, somehow get traceur out of it, and then require the resulting file into my otherwise fully working ES6 environment. I take a nice, tested, ES5 version any day over that experience.
2 replies →
I don't think you can really call something "a dinosaur" when the standard that is supposed to supersede it hasn't even formally been published yet!
The fiction that formal publications of standards matter should not be propagated. Implementations are well under way.
(I say this as a member of the TC39 committee in charge of the ECMAScript standard.)
I think a better option might be to use some kind of flag in `package.json` -- kinda like the `engines` flag.