Skip to content
This repository has been archived by the owner. It is now read-only.

Outdated V8 Versions #9162

Closed
ghost opened this Issue Feb 8, 2015 · 24 comments

Comments

Projects
None yet
@ghost
Copy link

ghost commented Feb 8, 2015

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

This comment has been minimized.

Copy link

lazdmx commented Feb 9, 2015

+1

@liveinjs

This comment has been minimized.

Copy link

liveinjs commented Feb 9, 2015

++1

@nacholibre

This comment has been minimized.

Copy link

nacholibre commented Feb 9, 2015

++, at least we have iojs..

@golyshevd

This comment has been minimized.

Copy link

golyshevd commented Feb 9, 2015

+1

2 similar comments
@callumacrae

This comment has been minimized.

Copy link

callumacrae commented Feb 9, 2015

+1

@gyandeeps

This comment has been minimized.

Copy link

gyandeeps commented Feb 9, 2015

+1

@tjfontaine

This comment has been minimized.

Copy link

tjfontaine commented Feb 9, 2015

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

This comment has been minimized.

Copy link
Author

ghost commented Feb 10, 2015

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

This comment has been minimized.

Copy link

StevenDStanton commented Feb 10, 2015

@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

This comment has been minimized.

Copy link

trevnorris commented Feb 11, 2015

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

This comment has been minimized.

Copy link
Member

indutny commented Feb 11, 2015

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

This comment has been minimized.

Copy link
Member

indutny commented Feb 11, 2015

@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

This comment has been minimized.

Copy link

trevnorris commented Feb 11, 2015

@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

This comment has been minimized.

Copy link
Member

indutny commented Feb 11, 2015

@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

This comment has been minimized.

Copy link

trevnorris commented Feb 11, 2015

@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

This comment has been minimized.

Copy link
Member

indutny commented Feb 11, 2015

@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

This comment has been minimized.

Copy link

trevnorris commented Feb 11, 2015

@indutny His opinions are not my opinions. :)

@indutny

This comment has been minimized.

Copy link
Member

indutny commented Feb 11, 2015

@trevnorris right, you never said that.

@shivajivarma

This comment has been minimized.

Copy link

shivajivarma commented Feb 16, 2015

+1

@orangemocha

This comment has been minimized.

Copy link
Member

orangemocha commented Feb 16, 2015

@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

This comment has been minimized.

Copy link

xpepermint commented Apr 27, 2015

+1

@csvan

This comment has been minimized.

Copy link

csvan commented May 18, 2015

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

https://github.com/Microsoft/node

@jasnell

This comment has been minimized.

Copy link
Member

jasnell commented May 19, 2015

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

This comment has been minimized.

Copy link
Member

jasnell commented Jun 5, 2015

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

@jasnell jasnell closed this Jun 5, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.