More info will be added shortly to http://iojs.org/
See also http://nodeforward.org/
There is a lot going on, and it is a little difficult to keep track of everything, for sure.
Just know that io.js will be node and npm compatible.
IO.js, a Node fork
21–30 of 30 posts
Re: IO.js, a Node fork
#22This has been brewing for a while. I don't know most of the people involved but they post youtube videos of their meetings. isaacs is involved and get is the creator of npm so that is a good sign. As I understand it this is a direct backlash against joyent's governance of node and it's slow release cycle.
Wired's quote from Joyent is, to me, rather telling:
"But for Joyent CTO Bryan Cantrill, Node is alive and well, despite the slower pace of development. He says that Joyent has been focused on making Node faster and more stable, rather than adding new features. “You’ve got to look at the quality of contributions,” he explains, “not the quantity.”"
Re: IO.js, a Node fork
#23So for those who wonder: In the TC meeting today we came up with a vision for the first release. First, a few assumptions we've internalized that probably need to be stated for this to make sense. - Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests. - Releasing more frequently leads to a more stab…
So, they're going to change a few things around the build process and versioning? I wonder if there will be any plans to address core functionality, namely callbacks vs promises.
Re: IO.js, a Node fork
#24A lot of confusion about why this is going on. My take as a very interested user who has been actively tracking down info about this Node's next release and possible fork for some time is this:
Node.js's last supported release uses such an old version of Google's V8 that this V8 version is itself no longer supported. This, in my opinion, is just not good enough. In my personal experience, when a release cycle gets that fucked up there's a reason.
Joyent hasn't shared what the reason actually is for the delay, but so many of the top contributors think they can do better with a fork, and I'm going to give them the benefit of the doubt.
The plan is to do weekly releases, semver, to keep absolutely up to date with Google V8, and incidentally to not let just one interested party dictate their future directions.
It's a good plan and if they follow through, I'm definitely on board.
Re: IO.js, a Node fork
#25So for those who wonder: In the TC meeting today we came up with a vision for the first release. First, a few assumptions we've internalized that probably need to be stated for this to make sense. - Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests. - Releasing more frequently leads to a more stab…
So, they're going to change a few things around the build process and versioning? I wonder if there will be any plans to address core functionality, namely callbacks vs promises.
I assume language features remain the domain of the V8 engine, which is pulled in from Google.
Re: IO.js, a Node fork
#26Earlier quoted context omitted.
So, they're going to change a few things around the build process and versioning? I wonder if there will be any plans to address core functionality, namely callbacks vs promises.
I assume language features remain the domain of the V8 engine, which is pulled in from Google.
The parent was referring to how, in the Node world, typically errors are the first argument of a callback function(err, value). Promises will be added to Node soon, but the question was whether they will change all of their APIs to use those instead of the current callback method.
Re: IO.js, a Node fork
#27Earlier quoted context omitted.
I assume language features remain the domain of the V8 engine, which is pulled in from Google.
The parent was referring to how, in the Node world, typically errors are the first argument of a callback function(err, value). Promises will be added to Node soon, but the question was whether they will change all of their APIs to use those instead of the current callback method.
precisely
Re: IO.js, a Node fork
#28So for those who wonder: In the TC meeting today we came up with a vision for the first release. First, a few assumptions we've internalized that probably need to be stated for this to make sense. - Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests. - Releasing more frequently leads to a more stab…
So, they're going to change a few things around the build process and versioning? I wonder if there will be any plans to address core functionality, namely callbacks vs promises.
Yeah. I'd love to see a node/npm fork that used es6 modules instead/as well as npm modules, and promises instead of callbacks throughout the api. Everything else the same, but something that will use the newer stuff that is becoming available a bit sooner than the node ecosystem will.
Re: IO.js, a Node fork
#29Not looking for dirt or anything, but why the fork? What makes this different from Node? (Only clue so far is the "open governance model"; is that in contrast to Joyent maintaining Node?) EDIT: Based on their CONTRIBUTING.md page[1], it looks like this is intended to be a more "community-driven" version of Node. A strike against is that SEVERAL (if not most) links in README.md and CONTRIBUTING.md still reference the…
Because Node 0.12 took forever to be released, looks more and more like vaporware, and the community demands new V8 features yesterday. Oh, and the V8 version bundled with the current stable Node was no longer maintained even at launch time.
Re: IO.js, a Node fork
#30This has been brewing for a while. I don't know most of the people involved but they post youtube videos of their meetings. isaacs is involved and get is the creator of npm so that is a good sign. As I understand it this is a direct backlash against joyent's governance of node and it's slow release cycle.
Wired's quote from Joyent is, to me, rather telling: "But for Joyent CTO Bryan Cantrill, Node is alive and well, despite the slower pace of development. He says that Joyent has been focused on making Node faster and more stable, rather than adding new features. “You’ve got to look at the quality of contributions,” he explains, “not the quantity.”"
Node.js issues in my mind now are maintainability related, not performance related. They need to stop fetishizing performance and focus more on making node.js more accessible/easier to work with.