No mention which version of V8 they use. Did they sync with what Chrome is using nowadays?
Anyways, I've already switched to iojs. I'm sharing part of my code between server and client and it has become increasingly painful to work around the lack of progress on the nodejs side of the network.
Because Chrome and Firefox now provide many ES6 features which are missing from nodejs. But iojs tracks the latest stable v8 so it is feature-wise at the same level as Chrome.
Node inspector should now work properly like it does on iojs (https://github.com/joyent/node/issues/7102) but this still isn't a stable v8, according to the v8 maintainers.
io.js is built against a much more current version of V8, which notably has default-on support for a lot of ES6 stuff.
Quite frankly, as a casual node user myself, I'm sticking with node v0.10 for the time being. I want to see how everything shakes out, and my site runs okay for now.
My experience has been that just about every module that uses native code (there are more than you think) doesn't work in IO.js because of the changes to the V8 apis. So until all of those are updated to work with both I'll have to stick to Node.
I've had the opposite experience. I've only had a couple modules that use native code that haven't worked, and most of those monkeyed directly with V8 so I wasn't terribly surprised they didn't work with the upgraded version.
As a native module owner, I made mine work right away and it was work that I needed to do anyway for Node compatibility because changes in v0.11.13/15 broke me as well.
3.24.x represents a significant departure from previous v8 APIs. Specifically, the v8 team moved from what I would term, 2nd Generation VM Primitives to 3rd Generation VM Primitives, including 2nd Gen Isolates, GC changes, UTF8/ASCII changes, and other siginificant API changes, in December 2013). Details can be found here [0] in the v8 team's "Design Doc Tracker". Up until late 0.11.x series, nodejs was based on v8 3.14.x, whose last commit by the v8 team was in May 2013, nearly two years ago. Needless to say, there were many changes/optimizations it was lacking. And even if they were to base nodejs on the latest 3.28.x (3.28.73), its last commit was August 2014, 6 months old. It seems odd to me, that they made the effort to get to 3.28.x but didn't go past 3.29.x because of the i18n changes v8 introduced. It's really easy to exclude that stuff if you don't want to deal with it. Bonehead move in my opinion.
It's based on node.js from just before the 0.12 stable release. The v8 and libuv base libraries and other pieces have been updated. It's not like they started io.js from scratch. It's that most of the core developers have moved on to io.js at this point.
Barring a merge back into node.js (which could still happen), I don't see myself going back for new projects.
iojs is definitely not the "standard" by any means... It's accelerating at a quick pace, but I haven't heard of any major sites making the switch yet. Many native modules (node-gyp compiled) aren't functioning yet, and the streams module was a bit finicky as of a couple weeks back. I'm looking forward to the market competition actually. Can't go wrong with having two standards battle to be the best.
Modules are quickly switching to using nan, which is required anyway for working with both 0.10 and 0.12, so io.js merely accelerated the incentive to use it.
As far as "big sites", several are starting to roll out io.js deployments. Most places don't blog about every upgrade to every internal piece of infrastructure. If you're doing the SOA thing properly, you can start rolling out io.js for new services without removing the versions of node used for other stuff.
At npm, we have some io.js, lots of node 0.10, erlang, java, spidermonkey, python, redis, postgres, etc. It's pretty common to use different stuff side by side in little servers that talk to one another. Less dramatic to talk about than pretending your'e gonna make some big switch-over though.
I am just curious, what happens when people start writing ES6 io.js modules and posting them to NPM? Won't it be an issue for older versions of node? Is NPM going to start fragmenting because of this?
The npm registry is already used for a bunch of stuff that it wasn't really intended for (e.g. front-end UI components, coffeescript, etc.). One solution for projects that need older versions of node would be to transpile es6 dependencies using https://github.com/esnext/es6-module-transpiler for example.
Good to see that a new version is out - if anybody here wants to take it for a spin on Azure Websites, we at Microsoft just created a small one-click script[1] that installs this version.
So can I use generators without a --harmony-generators flag now? Surprised there aren't any mentions of ES6 in the blog, considering the competition from io.js.
Several have asked about node.js in contrast to io.js. It's fair to say that the emphasis of node.js at this point is on stability (including API stability, production debuggability/observability, etc.) and performance -- in that order. It definitely takes longer to release software when operating under these constraints; as the team writes in the linked blog entry:
We are also pleased to report that this release of Node.js has tests passing on all of our supported platforms. On the one hand, this seems obvious (what are tests for if not to verify before you release it?!), but this is actually the first release of Node.js that has operated under this constraint. Requiring that all tests pass before releasing Node.js marks an important development for the project, and is essential for building a solid path moving forward.
It's unclear what the divergence will be in the future, but the emphasis of the node.js team on stability may or may not be shared by io.js -- and in particular, this may be reflected in things like the V8 version, changes in which tend to subtly break esoteric things on different platforms. Inasmuch as the divergence represents different operating principles (i.e., enterprise-grade stability vs. bleeding edge), it may well be helpful -- and I think it's entirely conceivable that the projects will develop a symbiotic relationship moving forward.
Why don't you push nodejs forward and track the latest v8 (or whatever the latest stable chrome is using), and then cut LTS releases at regular intervals, kindof like the kernel or ubuntu?
Also, are these tests public? How many does iojs pass/fail?
The idea of a "maintained" V8 is a bit of a myth -- there really isn't such a thing. Mostly, when V8 breaks node.js (e.g., by changing/eliminating a C++ API or by implicitly or explicitly breaking debugging support), node.js has to change. In that regard, it just takes a while to get a version of V8 fully integrated and operating correctly on all platforms -- and I think it would be valuable for the core team to blog some of the history and technical details here...
That's not true and the v8 team's stance is pretty clear. The master branch is the only "fully supported" code base, currently at 4.2.56 [0]. Most other tagged versions going back a year or two receive best effort support. Usually, that means Ben Noordhuis, but often Andreas, Yang, Vyacheslav, and others on the v8-users and & v8-dev lists. Good responses all around in general. And the list of responsive people continues to grow.
Amongst other things, Bryan Cantrill is the CTO of Joyent, one of the authors of DTrace, and comments here regularly. If you use node (or DTrace, or ZFS) and read HN, he's pretty hard to miss.
There's certainly something to be said for stability, but node continues to use abandoned versions of the V8 engine, which, increasingly, is going to be a problem.
Software does tend to remain stable if you never make any changes to it, but that's not necessarily the right path.
Oh well, if nothing else, this whole io.js thing has set fire to joyent. It's nice to see something happening at last.
I think mostly about the end users, those who depend on the software.
The last thing you want is to get some weird errors because of a bug in the latest V8 engine. Those bugs tend to never show in development, and is not found in unit testing. But will show up in production when you have thousands of people using it. And there's often nothing you can do about them, then maybe downgrading, or wait for the next Node.JS version.
I'm really excited that this version of Node includes updates I made for the debugger module[0], including the ability to show you the closures in your program[1]. (This has already helped nail some memory issues in Node itself.) I hope to blog about it in more detail next week.
This is fantastic. I know we'll be using the closures feature ourselves to debug our production problems. This is what I love to see in robust software releases -- features that help engineers more easily debug problems. Kudos dap!
"People" including major companies with huge teams of dev-ops.
It's not like 0.x universally means "not production ready" and you know better to school them.
The version number only has a meaning within the culture of a specific project. For node, they decided to keep using the 0.x release number long after the product was mature for production use.
It's been 5 years since node.js is around? is node.js development slow or the version numbers (scheme) is progressing slow. It sounds like there is at least a decade for ver 1.0. Probably 1.0 does not mean anything. In my mind version 1.0 is the when the product is complete.
Don't stare yourself blind at version numbers, they're just a way to distinguish one version from another.
Open source projects generally don't follow the same versioning conventions as closed source projects, as they don't require you to fork over money for each sharp version.
Also, software can rarely ever be said to be "complete", even theoretically. Only very small programs can be written once and be said to fulfil their purpose from then on. For larger programs and systems, the needs and requirements is usually something you try to approximate with ever increasing precision. But usually needs and requirements is a moving target as well, making this task perpetual.
This conspires to make 1.0 more of a marketing decision than to map to any real "completeness". I've seen whole program rewrites in a 0.01 change of an open source project. Similarly I've seen projects bumped to 1.0 with very little ceremony simply because it's been used in production for 8 years now, and why the hell not?
I actually looked but couldn't find it in my links, but out there on the internet somewhere is an interesting marketing study showing how profoundly more likely people are to pay for software that is versioned at least 1.0. All of my personal projects are 0.x.x, rarely making it to 1.0. Meanwhile, my business projects rarely start under 1.0.
80 comments
[ 2.8 ms ] story [ 142 ms ] threadAnyways, I've already switched to iojs. I'm sharing part of my code between server and client and it has become increasingly painful to work around the lack of progress on the nodejs side of the network.
How? And why is it a problem with node but not iojss?
io.js uses the current version of V8. node uses an outdated one.
Makes life easier if your code is being executed in the same engine, with the same version. Everything that works in one, works on the other.
Quite frankly, as a casual node user myself, I'm sticking with node v0.10 for the time being. I want to see how everything shakes out, and my site runs okay for now.
I'm using:
io.js v1.1.0
npm v2.4.1
node-gyp v1.0.2
https://github.com/iojs/io.js/issues/456#issuecomment-730639...
As a native module owner, I made mine work right away and it was work that I needed to do anyway for Node compatibility because changes in v0.11.13/15 broke me as well.
[0] https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7...
Barring a merge back into node.js (which could still happen), I don't see myself going back for new projects.
For one, it's a fork, not a new product -- so it carries all the old development from node.
Second, it got all the best contributors from the node community.
So, while it might not be a standard yet in numbers, it's very well poised to be.
As far as "big sites", several are starting to roll out io.js deployments. Most places don't blog about every upgrade to every internal piece of infrastructure. If you're doing the SOA thing properly, you can start rolling out io.js for new services without removing the versions of node used for other stuff.
At npm, we have some io.js, lots of node 0.10, erlang, java, spidermonkey, python, redis, postgres, etc. It's pretty common to use different stuff side by side in little servers that talk to one another. Less dramatic to talk about than pretending your'e gonna make some big switch-over though.
You don't see many people using `node.http.cat()` any more, for example. And yet the community survived ;)
I hope they have enough Timothy J Fontaines.
[1]: https://github.com/felixrieseberg/node12-azure
We are also pleased to report that this release of Node.js has tests passing on all of our supported platforms. On the one hand, this seems obvious (what are tests for if not to verify before you release it?!), but this is actually the first release of Node.js that has operated under this constraint. Requiring that all tests pass before releasing Node.js marks an important development for the project, and is essential for building a solid path moving forward.
It's unclear what the divergence will be in the future, but the emphasis of the node.js team on stability may or may not be shared by io.js -- and in particular, this may be reflected in things like the V8 version, changes in which tend to subtly break esoteric things on different platforms. Inasmuch as the divergence represents different operating principles (i.e., enterprise-grade stability vs. bleeding edge), it may well be helpful -- and I think it's entirely conceivable that the projects will develop a symbiotic relationship moving forward.
Also, are these tests public? How many does iojs pass/fail?
Rod Vagg has a project called NAN[0] to try and allow node modules to compile across node versions.
[0] https://github.com/rvagg/nan
[0] https://github.com/v8/v8-git-mirror/tree/4.2.56
Edit: Also, you should probably mention that you work for Joyent.
Software does tend to remain stable if you never make any changes to it, but that's not necessarily the right path.
Oh well, if nothing else, this whole io.js thing has set fire to joyent. It's nice to see something happening at last.
I guess competition is a good thing.
The last thing you want is to get some weird errors because of a bug in the latest V8 engine. Those bugs tend to never show in development, and is not found in unit testing. But will show up in production when you have thousands of people using it. And there's often nothing you can do about them, then maybe downgrading, or wait for the next Node.JS version.
[0] https://www.joyent.com/developers/node/debug/mdb
[1] https://github.com/joyent/node/issues/8718
It's not like 0.x universally means "not production ready" and you know better to school them.
The version number only has a meaning within the culture of a specific project. For node, they decided to keep using the 0.x release number long after the product was mature for production use.
Open source projects generally don't follow the same versioning conventions as closed source projects, as they don't require you to fork over money for each sharp version.
Also, software can rarely ever be said to be "complete", even theoretically. Only very small programs can be written once and be said to fulfil their purpose from then on. For larger programs and systems, the needs and requirements is usually something you try to approximate with ever increasing precision. But usually needs and requirements is a moving target as well, making this task perpetual.
This conspires to make 1.0 more of a marketing decision than to map to any real "completeness". I've seen whole program rewrites in a 0.01 change of an open source project. Similarly I've seen projects bumped to 1.0 with very little ceremony simply because it's been used in production for 8 years now, and why the hell not?