V8 Release 5.0 (upcoming)(v8project.blogspot.com)
v8project.blogspot.com
V8 Release 5.0 (upcoming)
http://v8project.blogspot.com/2016/03/v8-release-50.html
31 comments
How does nodejs sync with V8 releases? ECMA-version, V8-version, Node-version, Javascript-version, browser-version with different features support, it's quite a bit.
Node.js Stable tries to follow the V8 version from latest stable Chrome quite closely (i.e. soon after the corresponding Chrome release), but occasionally a V8 version may be skipped, e.g. if it has problematic API changes.
Node.js LTS branches stay on a fixed V8 version.
Node.js LTS branches stay on a fixed V8 version.
we just managed to get plv8 tracking against the same v8 versions as node (4.4-4.10).
v8 moves very quickly, and even the redhat/debian package maintainers are still distributing 3.14.
v8 moves very quickly, and even the redhat/debian package maintainers are still distributing 3.14.
This is a nice release.
I've always been confused about V8 versioning. Breaking changes appear to come all the time in minor versions.
And there's this note from the release:
> Note: The version number 5.0 does not carry semantic significance or mark a major release (as opposed to a minor release).
So what does it mark? Why 5.0 at all then?
I've always been confused about V8 versioning. Breaking changes appear to come all the time in minor versions.
And there's this note from the release:
> Note: The version number 5.0 does not carry semantic significance or mark a major release (as opposed to a minor release).
So what does it mark? Why 5.0 at all then?
They changed their versioning process to align with Chrome. Chrome 50 == v8 5.0, Chrome 51 == v8 5.1, etc.
Correct.
Major versions make more sense when you create a release based on the content. V8 is creating its releases based on time (~6 week cadence). So a 'major' version is nothing special anymore. In 4.9 we greatly expanded our ES2015 support which was huge but only incremented the minor version because of the same reason.
Disclaimer: I work on the V8 team.
Major versions make more sense when you create a release based on the content. V8 is creating its releases based on time (~6 week cadence). So a 'major' version is nothing special anymore. In 4.9 we greatly expanded our ES2015 support which was huge but only incremented the minor version because of the same reason.
Disclaimer: I work on the V8 team.
Why not date-based version numbers, then, or as bryanlarsen stated, something obviously meaningless, like the Chrome/FF numbers?
Edit: By the way, sorry to derail the conversation. You guys are doing great work! I'm always excited about V8 updates because they generally mean great perf/feature improvements to both the most popular browsers and my runtime of choice, NodeJS.
Edit: By the way, sorry to derail the conversation. You guys are doing great work! I'm always excited about V8 updates because they generally mean great perf/feature improvements to both the most popular browsers and my runtime of choice, NodeJS.
The reason is simply 'legacy'. Maybe we will change our version numbers to something without major.minor versions.
Maybe this is a stupid question... But why not straight up copy Chrome and jump up to v50 instead of v5.0?
If you're going to use meaningless version numbers, then it would be better if you used something that didn't imply otherwise. Chrome 50 carries exactly the right connotation, IMO.
Incidentally, I found a nice list of upcoming Chrome/V8 features and status here: https://www.chromestatus.com/features
Optimisations for ES6 features is great!
Any idea how V8 releases relate to Node (especially now post-io.js)? When could we see these improvements on the server?
Any idea how V8 releases relate to Node (especially now post-io.js)? When could we see these improvements on the server?
Node.js is easy to compile from sources. Basically when https://github.com/nodejs/node/pull/5592 gets merged, all that is needed is
git clone [email protected]:nodejs/node.git; cd node ; git checkout vee-eight-5.0; ./configure; make; make install
to start experimenting.
git clone [email protected]:nodejs/node.git; cd node ; git checkout vee-eight-5.0; ./configure; make; make install
to start experimenting.
> Any idea how V8 releases relate to Node (especially now post-io.js)? When could we see these improvements on the server?
April and October are the planned release months for a new major node version AFAIK. The April releases then become LTS releases in October. October releases don't become LTS.
Presumably new major node versions will be cut from the latest stable (or perhaps stable - 1, depending on timing) V8 release.
Might be wrong about this, so I'm open to correction.
April and October are the planned release months for a new major node version AFAIK. The April releases then become LTS releases in October. October releases don't become LTS.
Presumably new major node versions will be cut from the latest stable (or perhaps stable - 1, depending on timing) V8 release.
Might be wrong about this, so I'm open to correction.
Anyone know the V8 version that they are targeting for node.js 6?
There are some sweet features in ES6 V8 4.9 that I would love to start using including optional arguments and array based destructuring.
There are some sweet features in ES6 V8 4.9 that I would love to start using including optional arguments and array based destructuring.
Any idea when ES6 modules (via the <module> HTML tag) are coming?
We just sent out an intent to ship this week! [0] They're trickier to implement than other ES6 features since they require coordination with the Blink side of Chromium.
[0]: https://groups.google.com/a/chromium.org/forum/#!topic/blink...
[0]: https://groups.google.com/a/chromium.org/forum/#!topic/blink...
I've heard there's some V8 changes coming down the pipeline that will end up allowing node to use the serialport package without compiling anything native.
Have I heard wrong?
Have I heard wrong?
Something related to debugging? Perhaps you came across this thread? https://github.com/nodejs/node/issues/2546#issuecomment-1893...
Surely I'm not the only one asking "what is this/should I care?"
(three clicks later...) V8 is a javascript engine that supports web assembly.
(three clicks later...) V8 is a javascript engine that supports web assembly.
V8 is the js engine. The one that is so fast because it compiles in JIT, the one that powers Chrome and Node.js, the one that enabled a full range of let's-build-a-full-app-in-a-browser apps.
Also for the worse: the one that lets us include 10Mb of js in a browser.
Also for the worse: the one that lets us include 10Mb of js in a browser.
>The one that is so fast because it compiles in JIT
That's true for all modern JS engines (JavaScriptCore, Edge, SpiderMonkey, v8) and has been for several years (almost a decade).
That's true for all modern JS engines (JavaScriptCore, Edge, SpiderMonkey, v8) and has been for several years (almost a decade).
But only after V8; before that, JS performance had no priority in browsers.
That's a common mistake, but JITs in WebKit and Gecko came out at around the same time as v8. Their development began before v8 launched.
edit: For example, see the dates on Wikipedia, v8 launched September 2008, and WebKit's Nitro (SFX) JIT launched in the same month.
https://en.wikipedia.org/wiki/WebKit#JavaScriptCore
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
edit: For example, see the dates on Wikipedia, v8 launched September 2008, and WebKit's Nitro (SFX) JIT launched in the same month.
https://en.wikipedia.org/wiki/WebKit#JavaScriptCore
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Nope.
In fact Mozilla was somewhat earlier to come up with their JIT-ed JS engine, then Google (v8), then Apple (JSC), but all went live with an insignificant time difference between them (all within a few months in 2008).
(Insignificant since the respective companies have already been working on them simultaneously for years -- so going live was mostly based on who wrapped up first, bugs be damned, not on some unique innovation that others later copied).
In fact Mozilla was somewhat earlier to come up with their JIT-ed JS engine, then Google (v8), then Apple (JSC), but all went live with an insignificant time difference between them (all within a few months in 2008).
(Insignificant since the respective companies have already been working on them simultaneously for years -- so going live was mostly based on who wrapped up first, bugs be damned, not on some unique innovation that others later copied).
To give you more context, it is not just "a" javascript engine. It is the engine behind node.jj, Google Chrome, and others!
I'm sure the problem in your case is that apparently the blog is hosted off-site from the v8 project's site; you need to go to the homepage (v8project.blogspot.com) and find a link on the right side to get to https://github.com/v8/v8/wiki, which has a short introduction to what v8 is. It's a bit underwhelming, really.
Yes, you are probably the only one.
This may be true, but as an embedded developer my world is quite different from the fullstack work many of the rest of audience here.
I could have phrased it more delicately, but I assure you I wasn't being a smart-alek. There is a steady stream of new/unfamiliar tools discussed here and I find that I'm frequently clicking just to find out what it's all about.
I could have phrased it more delicately, but I assure you I wasn't being a smart-alek. There is a steady stream of new/unfamiliar tools discussed here and I find that I'm frequently clicking just to find out what it's all about.