Node v0.12.0 (Stable) | Hacker News Reader

Node v0.12.0 (Stable)

blog.nodejs.org

170 pointsTimWolla74 comments

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.

[0] https://www.joyent.com/developers/node/debug/mdb

[1] https://github.com/joyent/node/issues/8718

This sounds really interesting. I'm excited to see your blog post.

@dap, that's very excited work! Would love to sit with you soon and watch you use the debugger with these enhancements.

Cool idea. I'll be demo'ing them at NodeSummit too!

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!

If anyone's still following this thread, the blog post is up: https://www.joyent.com/blog/debugging-enhancements-in-node-0...

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.

Nope. They're using V8 3.28.73 and libuv 1.0.2, both of which are abandoned by their maintainers.

iojs 1.1.0 V8 version 4.1.0.14 (current). nodejs 0.12 V8 version: 3.28.73 (>6 months old). More info here: https://iojs.org/es6.html

> I'm sharing part of my code between server and client

How? And why is it a problem with node but not iojss?

You can easily use the same framework both on the server and client, especially a general purpose one. Makes life easier.

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.

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.

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.

[1]: https://github.com/felixrieseberg/node12-azure

They didn't catch up on v8 and libuv and they didn't deliver the supported C++ API. Congrats on the release, but it's kind of disappointing.

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.

Answering my own question: nope!

This is by far the most disappointing bit of the release for me. Catch up with the V8 releases already!

I am glad this is out but bummed about the V8 engine being so old. I see why IO.JS is a thing now but I also understand you want stability as well.

I disagree with the assumption that old === stable.

Meh, too late. io.js is the standard now.

Yep, io.js v1.1 works really fine and i switched too.

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.

Example? I'm curious because mostly everything has worked for me.

I'm using:

io.js v1.1.0

npm v2.4.1

node-gyp v1.0.2

fibers

I just crudely tested this pull request. Seems to work. https://github.com/laverdet/node-fibers/pull/205/files

Right the fix was submitted a few days ago. I couldn't get meteor to work on iojs

Ursa

That is being tracked here:

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.

I am neither side of this fight , Can you explain what is this V8 api story ? seems this is root of all fight in *.js community

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.

[0] https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7...

Not sure if this is a joke, but assuming it's not - it's the standard now, and it's been out for... 2 whole months?!

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.

That's a fine attitude, but nothing about it justifies talk of "standard".

For us JS bystanders who get whiplash from release announcements, I think it's pretty hilarious. I definitely read it as a joke.

What does the time it's "been out" has to do with anything?

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.

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.

Sure, but no worse (or even all that different) from any other Node release. The community will gradually upgrade, and it'll be fine.

You don't see many people using `node.http.cat()` any more, for example. And yet the community survived ;)

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.

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?

That is the plan for io.js. Doing releases often and LTS at some interval.

How does the stability concern gel with a unmaintained v8?

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

The io.js team is working alongside the V8 team to make sure that the upgrades are as easy as possible.

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

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.

[0] https://github.com/v8/v8-git-mirror/tree/4.2.56

A little disingenuous to say the tests pass when they landed this PR: https://github.com/joyent/node/pull/8689

Edit: Also, you should probably mention that you work for Joyent.

He probably should, but then, almost everybody using both node and HN knows who he is.

I don't know why you assume that. Who is he anyways and why do you expect HN+node folks to know who he is?

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.

I use Node and Hacker News every day. I have no idea who he is. I'm not some rube, I just don't pay much attention to personalities in tech like that.

I use node and read HN, I had no idea who he was. I'm not ignorant, I just don't care much about 'celebrities'.

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 guess competition is a good thing.

Most people will appreciate stability more then language features. I'm a bit surprised about some of the comments here.

How do you know? Was there a poll recently about who prefers stability over progress?

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.

Competition at its best! Days after io.js gets released, node.js outs a major release.

With a year and a half old engine, worse performance and none of the new language features like generators :D

It's true, but they are mobilizing, which is good.

As a casual node user, I'd love to better understand how this release compares to io.js. Are they diverging more? Is node playing catch-up?

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.

I think the next security "situation" in node and/or io will be a key decision point for many of us in similar situations.

Both this and io.js 1.1.0 are available via nvm now.

I would just like to point out people are running production stuff on v0.x of something..

Yes, but what's your point? That version numbers aren't the best indicator for production readiness?

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

Awesome! Even better, will Joyent pay me to use it? https://news.ycombinator.com/item?id=8996797

I hope they have enough Timothy J Fontaines.

"Pay" seems like a stretch. The only "money" is in Joyent hosting credit, no?

Reply on news.ycombinator.com