Outdated V8 Versions

[ghost]

Is there any chance of Node ever catching up with the latest stable release of V8?

There are currently a lot of improvements being made to the JS language (ES6) and, unfortunately, the V8 version used by Node always seems to be at least four months out of date. For example, Node 0.12 introduced ES6 generators and iterators which were available in Chrome 38 (released October 2014).

ES6 classes will be landing in Chrome soon, enabled by default, and it would be great to be able to start using those in Node scripts at the same time.

[lazdmx]

+1

[liveinjs]

++1

[nacholibre]

++, at least we have iojs..

[golyshevd]

+1

[callumacrae]

+1

[gyandeeps]

+1

[tjfontaine]

Yes, Node.js will definitely be upgrading to a newer version of V8, and we are working to improve our roadmap and scoping such that our releases are more predictable.

The question is how does Node.js architect itself in light of the release schedule for V8.

There is no doubt that one of the major factors in Node.js success was the adoption of V8. It's an incredible JavaScript VM, and it has served Node.js very well for executing our JavaScript. What hasn't always been easy is the fact that we are tightly coupled to the V8 APIs and semantics. This means that even subtle changes upstream can induce a significant burden on the downstream (us) as those changes are integrated and validated.

The pace at which V8 is developed and upgraded is influenced heavily by the Chromium release cycle. The distribution, consumption, and upgrade patterns of people who use Chromium/Chrome are very different from people who are writing server side JavaScript and the Node.js framework. Some may be able to start integrating changes on new apps and delivering those new codebases on newer versions, other apps and users may have to rely on an older version which is currently in production and understand what it means to develop for those versions.

To balance these competing desires: a fast, stable, high quality, production ready core with bleeding edge ES features and newer JIT and optimizations -- I would argue that Node.js should not just be accepting newer version of V8 and pinning our release cycle to that portion of the upstream. Instead I would propose that Node.js architect itself in a manner that insulates it from V8 changes and opens a door to a wider set of runtimes.

We could validate and ship a version of V8 with our Node.js release, but also create a plugin/module architecture such that different VMs could be selected at runtime (startup). Consider being able to npm install -g v8-canary and then being able to node --runtime=v8-canary as a hypothetical.

This means Node.js could have a stable supported V8 (as in what the team is willing and able to support) on a release basis, but doesn't prevent users from opting into the versions of the runtime they want/need.

A lot of this same work can be put to good use for people who are looking to run Node.js on alternate runtimes, that could be SpiderMonkey, JavaScript Core (Hello Native IOS apps), or even the JVM (project Avatar) or Lua (technical's tessels) or duktape or I could go on and on. This could also apply to giving us a stable API/ABI that we can use for binary addons, and as a result they would also work across runtimes.

In short now that v0.12 has been released, we can start talking about and prototyping what it would mean to live in this kind of a world. Defining crisply what we want to support, how we support those things, and improving our infrastructure to support as many use cases we can.

In fact, I started on https://github.com/tjfontaine/node-addon-layer as a way to stratify v0.8 to v0.12 binary modules, this could be used as a jumping off point to build a prototype.

[ghost]

That sounds like a convoluted and volatile path to take @tjfontaine. I haven't studied Node's guts long enough to understand how it has been hooked up to V8 but I can't imagine V8 is released with public facing breaking changes too often. If Node is built upon a modified version of V8 then that would be the real problem here, not the frequency at which V8 updates are released.

I also don't understand why anyone would want to plug another JavaScript engine into Node, the selling point and power of Node comes from the fact it uses V8. Expecting someone to download JavaScript engine X version Y just to run a Node script that has been written specifically for that environment by someone is madness.

All we need is for Node to try and keep up with V8, at least while ES6 is appearing. Having Node running a four month old version of V8 at the moment is quite painful :)

[StevenDStanton]

@si-robertson I have to disagree.

The issue here is not V8 being released with changes to the API which break compatibility. The issue is you have a small team of developers working on this project where on the Chromium project you have the effective entire power of Google pushing forward to make it happen.

When a new version of V8 is released it is not as easy as them just slapping it into place. They have to go through and check that nothing has changed, then they have to test to make sure that no small internal change is going to cause any issues. This all takes time.

While you may not understand anyone wanting to plug another Javascript engine or another version of V8 into the program doesn't meant it is not something other people want.

Allowing other engines to be plugged in can only be a good thing. It will not effect the normal end user of the system who can use the default V8 build. It will allow developers to decide if they want to use another engine which may have some other benefit.

[trevnorris]

Simple answer. V8 won't be upgraded past 3.28 for v0.12 because it requires a C++11 capable compiler. Which is difficult for anyone building native modules on distros like EL 5/6. We do plan on upgrading to the latest V8 for the next major release.

[indutny]

I think what everybody forget to mention is the stability of V8 version itself. Old version are not supported and with bigger delta bugfixes are much more difficult to backport. It is already impossible to fix node.js v0.10 v8 bugs, and the more node.js will stay on older/unsupported versions - more harder it will be to have these versions actually stable.

[indutny]

@trevnorris My understanding is that EL 5/6 may use pre-built binaries on the machines without C++11 capable compiler. This should not be a big deal and, considering, the context of such deployments should be easily achievable.

[trevnorris]

@indutny True. IIRC the native module dependencies for older GCC's were the bigger concern. Not the binaries themselves. (e.g. can't just use npm install)

[indutny]

@trevnorris distribution of native module dependencies is obviously solvable too. Deciding not to solve this problems is similar to creating a technical debt, and could not be called anything but lazyness. What concerns me a lot is that that **lazyness* causes us to ship the stale code, putting the rest of non-lazy node.js users to the risk of using unsupported V8 version. I hardly imagine that this might be considered acceptable, but negotiations on this has apparently failed.

[trevnorris]

@indutny it's code. everything is solvable. ;-)

v0.12 was a long time coming, and personally I didn't want to do anything that would stall it any longer. Personally I believe (but since I don't have control over this can't give a guarantee) major releases should be released more frequently. So we shouldn't be stuck with 3.28 for very long.

[indutny]

@trevnorris when I'm reading:

The distribution, consumption, and upgrade patterns of people who use Chromium/Chrome are very different from people who are writing server side JavaScript and the Node.js framework.

I hear that @tjfontaine sees no reason to use up-to-date v8 version.

[trevnorris]

@indutny His opinions are not my opinions. :)

[indutny]

@trevnorris right, you never said that.

[shivajivarma]

+1

[orangemocha]

@indutny I understand your desire to have the latest features and bugfixes, but I think there's more to this v8 version delay than just laziness :) When you make such a change like a major v8 update there is a tail of bugs/instability for which you wouldn't want to publish a new "stable" release the next day. Better planning could help line up node releases better with v8 releases, and I guess we could have done a better job at that, but for whatever reason the schedules drifted apart, the ES6 proposal came late and given the mounting pressure to release 0.12, it was decided to postpone the v8 upgrade.
I think the multi-engine idea allows decoupling the release schedules of node vs v8, so that stable node releases can be cut with different v8 versions at different stability levels (eg stable vs experimental).

[xpepermint]

+1

[csvan]

Since someone mentioned other runtimes for Node, Microsoft has successfully ported it to Chakra:

https://github.com/Microsoft/node

[jasnell]

This conversation should move to the new LTS Working Group. It's highly unlikely that any of the v0.x streams will ever move to an updated V8 and the LTS WG will need to decide on a reasonable maintenance strategy for downlevel V8 in v0.10 and v0.12. If no one objects, we should close this issue here and transfer the discussion to http://github.com/nodejs/LTS /cc @joyent/node-coreteam

[jasnell]

Closing this discussion here. Continued discussion of newer v8 versions should happen either over in http://github.com/nodejs/node or http://github.com/nodejs/LTS