Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Io.js 1.0.0

iojs.org

Post reply on HN
Print view View original

81–90 of 190 posts

Re: Io.js 1.0.0

#81

Post by martinko »

frik wrote: post #65
elisee wrote: post #18

Earlier quoted context omitted.

io.js is a fork/continuation of Node.js "unstable" 0.11.x branch. Node.js stable, under Joyent's stewardship, has been stuck in 0.10.x land for over a year. io.js has many of the top core Node.js contributors. They're trying to move server-side JavaScript forward with open governance, faster release cycles, ES6, etc.

It will be interesting what Joyent will do with its 0.11 unstable branch and how popular io.js will get.

The merge between the current 0.10.35 branch and the 0.12 branch is almost done (https://github.com/joyent/node/milestones/0.11.15), we can expect version 0.11.15 within then next few days. 0.11.15 will be a release candidate for 0.12.

On the other hand, they've been saying that 0.12 will come out 'soon' for over a year, so this too may take longer than I expect.

Re: Io.js 1.0.0

#83

Post by jkrems »

wycats wrote: post #73
jkrems wrote: post #68

Earlier quoted context omitted.

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

Re: Io.js 1.0.0

#84

Post by tlrobinson »

_greim_ wrote: post #42

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 cod…

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

Re: Io.js 1.0.0

#85

Post by stepstep »

tuananh wrote: post #82

it seems it uninstall `node` when install itself.

It just overwrites the node symlink.

> "This package will install io.js v1.0.0 and npm v2.1.18 into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node."

Re: Io.js 1.0.0

#86

Post by malandrew »

_greim_ wrote: post #74
silversupreme wrote: post #27

Earlier quoted context omitted.

I find Ben's inclusion on this list interesting, given his history with Joyent/the node community.

I felt like he got thrown under the bus with that whole uproar, and was glad to see him in there.

With 1098 commits to libuv, which represents 35.2% of all commits to that project and the most number of commits from any single individual, and 1409 commits to node (13.8%, 3rd after Ryan Dahl and Isaac Schlueter), I'd say that him "getting thrown under the bus" is a huge understatement of what happened.

Re: Io.js 1.0.0

#88

Post by jkrems »

tlrobinson wrote: post #84
_greim_ wrote: post #42

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 cod…

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.

Re: Io.js 1.0.0

#89

Post by wycats »

jkrems wrote: post #83
wycats wrote: post #73

Earlier quoted context omitted.

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…

Once those steps are literally just "use iojs", I think the calculus is a little different, no?

Re: Io.js 1.0.0

#90

Post by tlrobinson »

jkrems wrote: post #88
tlrobinson wrote: post #84

Earlier quoted context omitted.

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…

What is 'the "synchronous require" problem'?

I've never run into issues with the CoffeeScript require hook, for example.

Post reply on HN