Comment by jkrems
11 years ago
> 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.
Once those steps are literally just "use iojs", I think the calculus is a little different, no?
1 reply →