7 ms·

October Brings Node.js 10.x to LTS and Node.js 11 to Current

162 points by truth_seeker 8y ago

Lerc 8y ago
The linked page seems to not contain the words 'compute' or 'latency' Is there a better link for the title or a better title for the link?
- tobyhinloopen 8y ago
  https://medium.com/@nodejs/october-brings-node-js-10-x-to-lts-and-node-js-11-to-current-ae19f8f12b51 https://medium.com/@nodejs/october-brings-node-js-10-x-to-lt...
egeozcan 8y ago
I don't see such a claim on the changelog. Am I missing it? Edit: The original title spoke about huge latency and performance improvements. It had been changed since I wrote this, hence this comment is now obsolete.
- vhbit 8y ago
  more likely that's compared to an earlier LTS version (8.x or 6.x)
- truth_seeker 8y ago
  https://benchmarking.nodejs.org/ https://benchmarking.nodejs.org/
deleted 8y ago
[deleted]
baq 8y ago
18 months is not what I call LTS. not even 30 months is LTS.
- jannes 8y ago
  JavaScript code is basically obsolete as soon as it is written... In that context 18 months might be a long time. Edit: I probably wasn't clear enough that I was joking. Edit 2: I also found out that the LTS release should receive 30 months of maintenance. They say that end of life for node 10 will be April 2021.
  - scandox 8y ago
    Well I have JS code that was written in 2005 that I know is still running in production. Even with Nodejs I have code running that is more than 6 years old happily doing useful stuff. So I'm not sure I understand your comment.
    - jannes 8y ago
      I wasn't entirely serious. There is just a lot of churn in the library/framework space for JS. There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. If you don't use npm and only rely on the builtin node APIs this would not apply to you as much, though. On top of that there are always new language features being introduced to EcmaScript and implemented in V8. This means that if you're not using those latest features, some might say your code is outdated.
      - scandox 8y ago
        Yeah sorry sense of humour failure on my part
      - fenomas 8y ago
        > There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. Complaints like this always mystify me. Would things be better if what you describe wasn't the case?
      - adrianhel 8y ago
        There was a lot of churn in JS. Things have gotten pretty damn stable. I usually use Express(2010), Socket.io(2014) and React(2013) for new projects. The libraries that break with new versions are the ones that rely on exotic features.
timjulien 8y ago
This other post contains the performance claims: https://medium.com/@nodejs/october-brings-node-js-10-x-to-lts-and-node-js-11-to-current-ae19f8f12b51 https://medium.com/@nodejs/october-brings-node-js-10-x-to-lt...
peterkelly 8y ago
Does anyone have a summary of the major changes from version 8? The changes are split up into lots of small increments in the changelog but it'd be good to see a summary.
- tybit 8y ago
  I’d love to know the performance improvements compared to 8 too, comparing 10 to 6 isn’t particularly useful though interesting.
jcolella 8y ago
If you are using async/await, you also enjoy a performance boost. https://auth0.com/blog/nodejs-10-new-changes-deprecations/ https://auth0.com/blog/nodejs-10-new-changes-deprecations/
Klathmon 8y ago
>This version also comes with the experimental release of Node-ChakraCore Wow, it looks like Microsoft is really truly supporting this! I have to be honest, when I first saw they were trying to run their engine in node, I thought it would be like all the attempts before. Half-assed, or done once then not kept up to date. But not only are they still maintaining it, but they are still improving it! I really hope that node-chakracore gains more adoption, even if only as an alternative from the v8 monoculture that we have. And that being said, I'm going off now to put my money where my mouth is and install it locally and see how much I can run with it.
- hajile 8y ago
  With Node's growing popularity, could you expect any different? Google and Apple compete on the cloud and node is very important there. By getting involved in the process, Microsoft keeps themselves from being at the mercy of Google's choices. Apple doesn't because Cloud is a much smaller part of their business (though native node on iOS and OSX would be very nice to have). Mozilla was also working on that, but I guess it's even less of a priority for them since they appeared to drop everything
  - Klathmon 8y ago
    But that's my point, is that I expected MS to stand it up, get it like 50-80% working, then drop it. It's happened a lot of times: * nashorn - started off as a reimplementation of node APIs in java's JS engine, died around 2015 for this purpose * rhinodo - same as the above, never really got anywhere. no change since 2015 * spidernode - mozilla's take on it, looks like most development started and ended 2 years ago, with only superficial changes since then. * node-jsc - still being developed, but it's only a few months old, and still isn't even fully caught up to node's version 8 APIs. The ground is littered with failed attempts at this, and I think that is because it's always a LOT more work than people think, and the work doesn't just stop when you get it running, it keeps going. And you either need a crazy amount of dedication, a wide audience, or a lot of funding to keep it up. And it's hard to stay dedicated without users, it's hard to get an audience when stuff doesn't work, and it's hard to keep funding when the work isn't providing any immediate benefit for your company. Don't get me wrong, I don't want to dissuade or put down developers working on those projects, I think it's an extremely awesome thing that's well above my ability and I hope that they continue so one day we can see competition in the server-side-javascript space similar to how we see competition in the browser space to really drive innovation. But this stuff isn't easy, and it is really nice to see a company say they are going to build this, then actually put their money down and fund it. And on top of that they are adding new features, new developer niceties, and actually working to make it a viable option, not just a checkbox and a pat on the back for giving it a good try.
abuldauskas 8y ago
Node 11 now comes with v8 v7.0, does this mean Webassembly threads are supported? Or are they behind a flag?
- lioeters 8y ago
  I was curious about this also, but couldn't find an answer. The most relevant thing I learned was that WebAssembly is exposed as a global object since Node.js 8.0.0, without a runtime flag. https://nodejs.org/api/globals.html#globals_webassembly https://nodejs.org/api/globals.html#globals_webassembly A list of WebAssembly features implemented by Node.js can be found here (the right most column): https://developer.mozilla.org/en-US/docs/WebAssembly#Browser_compatibility https://developer.mozilla.org/en-US/docs/WebAssembly#Browser...
- Operyl 8y ago
  ReferenceError: SharedArrayBuffer is not defined I couldn't get a basic example working because `SharedArrayBuffer` isn't available in node. I wouldn't be surprised if the other bits aren't either.
z3t4 8y ago
The native modules has been my biggest pain point, that modules stop working after a major release. Glad they are working on it! I try to use "pure" JS modules as much as possible, but it's not always possible when working with low level code, hardware, or OS integration.
jchw 8y ago
I am really disappointed with the direction ES module support has taken in Node.JS. It isn't like it was done poorly, in fact I think it was done quite thoughtfully... And yet it feels like it hurts ES modules very hard. Interoperabilility is just too poor. I don't even bother trying to use it. I'd rather continue using the polyfills.

162 points by truth_seeker 8y ago

Lerc 8y ago

The linked page seems to not contain the words 'compute' or 'latency' Is there a better link for the title or a better title for the link?

tobyhinloopen 8y ago
https://medium.com/@nodejs/october-brings-node-js-10-x-to-lts-and-node-js-11-to-current-ae19f8f12b51 https://medium.com/@nodejs/october-brings-node-js-10-x-to-lt...

egeozcan 8y ago

I don't see such a claim on the changelog. Am I missing it? Edit: The original title spoke about huge latency and performance improvements. It had been changed since I wrote this, hence this comment is now obsolete.

vhbit 8y ago
more likely that's compared to an earlier LTS version (8.x or 6.x)
truth_seeker 8y ago
https://benchmarking.nodejs.org/ https://benchmarking.nodejs.org/

deleted 8y ago

[deleted]

baq 8y ago

18 months is not what I call LTS. not even 30 months is LTS.

jannes 8y ago
JavaScript code is basically obsolete as soon as it is written... In that context 18 months might be a long time. Edit: I probably wasn't clear enough that I was joking. Edit 2: I also found out that the LTS release should receive 30 months of maintenance. They say that end of life for node 10 will be April 2021.
- scandox 8y ago
  Well I have JS code that was written in 2005 that I know is still running in production. Even with Nodejs I have code running that is more than 6 years old happily doing useful stuff. So I'm not sure I understand your comment.
  - jannes 8y ago
    I wasn't entirely serious. There is just a lot of churn in the library/framework space for JS. There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. If you don't use npm and only rely on the builtin node APIs this would not apply to you as much, though. On top of that there are always new language features being introduced to EcmaScript and implemented in V8. This means that if you're not using those latest features, some might say your code is outdated.
    - scandox 8y ago
      Yeah sorry sense of humour failure on my part
    - fenomas 8y ago
      > There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. Complaints like this always mystify me. Would things be better if what you describe wasn't the case?
    - adrianhel 8y ago
      There was a lot of churn in JS. Things have gotten pretty damn stable. I usually use Express(2010), Socket.io(2014) and React(2013) for new projects. The libraries that break with new versions are the ones that rely on exotic features.

timjulien 8y ago

This other post contains the performance claims: https://medium.com/@nodejs/october-brings-node-js-10-x-to-lts-and-node-js-11-to-current-ae19f8f12b51 https://medium.com/@nodejs/october-brings-node-js-10-x-to-lt...

peterkelly 8y ago

Does anyone have a summary of the major changes from version 8? The changes are split up into lots of small increments in the changelog but it'd be good to see a summary.

tybit 8y ago
I’d love to know the performance improvements compared to 8 too, comparing 10 to 6 isn’t particularly useful though interesting.

jcolella 8y ago

If you are using async/await, you also enjoy a performance boost. https://auth0.com/blog/nodejs-10-new-changes-deprecations/ https://auth0.com/blog/nodejs-10-new-changes-deprecations/

Klathmon 8y ago

>This version also comes with the experimental release of Node-ChakraCore Wow, it looks like Microsoft is really truly supporting this! I have to be honest, when I first saw they were trying to run their engine in node, I thought it would be like all the attempts before. Half-assed, or done once then not kept up to date. But not only are they still maintaining it, but they are still improving it! I really hope that node-chakracore gains more adoption, even if only as an alternative from the v8 monoculture that we have. And that being said, I'm going off now to put my money where my mouth is and install it locally and see how much I can run with it.

hajile 8y ago
With Node's growing popularity, could you expect any different? Google and Apple compete on the cloud and node is very important there. By getting involved in the process, Microsoft keeps themselves from being at the mercy of Google's choices. Apple doesn't because Cloud is a much smaller part of their business (though native node on iOS and OSX would be very nice to have). Mozilla was also working on that, but I guess it's even less of a priority for them since they appeared to drop everything
- Klathmon 8y ago
  But that's my point, is that I expected MS to stand it up, get it like 50-80% working, then drop it. It's happened a lot of times: * nashorn - started off as a reimplementation of node APIs in java's JS engine, died around 2015 for this purpose * rhinodo - same as the above, never really got anywhere. no change since 2015 * spidernode - mozilla's take on it, looks like most development started and ended 2 years ago, with only superficial changes since then. * node-jsc - still being developed, but it's only a few months old, and still isn't even fully caught up to node's version 8 APIs. The ground is littered with failed attempts at this, and I think that is because it's always a LOT more work than people think, and the work doesn't just stop when you get it running, it keeps going. And you either need a crazy amount of dedication, a wide audience, or a lot of funding to keep it up. And it's hard to stay dedicated without users, it's hard to get an audience when stuff doesn't work, and it's hard to keep funding when the work isn't providing any immediate benefit for your company. Don't get me wrong, I don't want to dissuade or put down developers working on those projects, I think it's an extremely awesome thing that's well above my ability and I hope that they continue so one day we can see competition in the server-side-javascript space similar to how we see competition in the browser space to really drive innovation. But this stuff isn't easy, and it is really nice to see a company say they are going to build this, then actually put their money down and fund it. And on top of that they are adding new features, new developer niceties, and actually working to make it a viable option, not just a checkbox and a pat on the back for giving it a good try.

abuldauskas 8y ago

Node 11 now comes with v8 v7.0, does this mean Webassembly threads are supported? Or are they behind a flag?

lioeters 8y ago
I was curious about this also, but couldn't find an answer. The most relevant thing I learned was that WebAssembly is exposed as a global object since Node.js 8.0.0, without a runtime flag. https://nodejs.org/api/globals.html#globals_webassembly https://nodejs.org/api/globals.html#globals_webassembly A list of WebAssembly features implemented by Node.js can be found here (the right most column): https://developer.mozilla.org/en-US/docs/WebAssembly#Browser_compatibility https://developer.mozilla.org/en-US/docs/WebAssembly#Browser...
Operyl 8y ago
ReferenceError: SharedArrayBuffer is not defined I couldn't get a basic example working because `SharedArrayBuffer` isn't available in node. I wouldn't be surprised if the other bits aren't either.

z3t4 8y ago

The native modules has been my biggest pain point, that modules stop working after a major release. Glad they are working on it! I try to use "pure" JS modules as much as possible, but it's not always possible when working with low level code, hardware, or OS integration.

jchw 8y ago

I am really disappointed with the direction ES module support has taken in Node.JS. It isn't like it was done poorly, in fact I think it was done quite thoughtfully... And yet it feels like it hurts ES modules very hard. Interoperabilility is just too poor. I don't even bother trying to use it. I'd rather continue using the polyfills.