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.
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.
? I work on large enterprise app in node there is code that was written 5 years ago and still works fine with 0 changes so not sure "JavaScript code is basically obsolete as soon as it is written" is applicable on the server side.
I’m a huge fan of Node.js, particularly in the enterprise, but I question your “0 changes...” claim. At the very least you’ll have to update dependencies to deal with breaks on their part due to upgrades.
As someone who has a fairly large codebase that's been largely untouched for 3-4 years, I'd disagree. Nothing has stopped me from updating some ancient dependencies. Perhaps we should make a difference between Node and semver-major library changes
it depends on how well engineered the application is, like anything.
I've been working on react-native recently, and this is by far the most difficult "framework" (or system, or library, or whatever else you want to call it) i've ever had to work with regarding dependencies.
Every. single. change. breaks. And it seems to have deep dependencies on exact versions of many other tools, and changing them causes all kinds of hell. It's awful, and it's what I see as "dependency hell". We are like 5 patch versions behind latest right now, but every other patch version between ours and current either won't build on one platform, won't start due to mismatched dependencies, requires an alpha version of react proper, or breaks all of our tests.
But before that i've worked on at least a dozen mid-sized+ node and browser based projects, and i've never had major issues with upgrades. For the most part they work if you stay within patch or minor versions, and even major upgrades only really hurt if you are impacted by the breakage, which in my experience is pretty rare (just looking at one monorepo-style project that has about 150 direct dependencies, i would probably spend about 2 hours a month on keeping them up to date, and just for fun, i went back to a commit from 3 years ago just now, and it still installs and runs fine.
If you stick to documented features, don't try to abuse or be clever with interfaces that aren't well defined, wrap any "iffy" libraries in your own interfaces to make switching or re-implementing them easier, and overall vet your deps a bit before installing them, it's pretty smooth sailing.
I think you're confused with javascript frameworks. Just vanilla NodeJS & "BrowserJS" is mostly backwards compatible. Old stuff that worked 10 years ago still mostly works fine.
To the contrary, JavaScript is one of the most portable and backward-compatible languages of all time. Portability and long-term maintenance on node.js is excellent if you stick to long-term development practices (commonjs, es5) and few core packages such as express.js. The only weak spot I encountered were subtle changes in error handling such as removal of auto-cleaning of resources with domain.dispose() back in v0.12 or v4 or so, and the somewhat unclear deprecation status of exception domains or the error handling/cleanup story in general, resp.
But it's not you who are releasing this version... Node.js calls 18 months LTS, then 18 months is LTS for Node.js. I believe Node.js does not follow SemVer, and if they do it's very, very strictly (like, a tiny change that affects 0.1% will be a major version, but there won't be changes that affect 10% unfortunately). So upgrades are very safe and shorter LTS are okay.
I mean, mandatory major bumps every 6-12 months means that they would make a major bump even if there's no breaking change. Not sure if that has happened, but that would be NOT following semver AFAIK since major releases are supposed to be only for breaking changes, not for arbitrary time progress. But yeah, if anything I'd say they are very strictly following it.
There are always breaking changes waiting to go in (https://github.com/nodejs/node/labels/semver-major). Often they’re edge cases or native extension things though. Although the choice on when is arbitrary timing, the major bump does mean there are breaking changes.
The nature of JS is that there are very few breaking changes allowed from an end-user perspective even between major versions.
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.
>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.
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
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.
I'm like 90% sure I read the w10 start menu is a javascript UWP app so I would imagine they're fairly committed to aligning their JS/uwp apps with the node world, and with node and browsers working to bring the module ecosystem together it's all shaping up to be one happy family...
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.
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.
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.
38 comments
[ 12.0 ms ] story [ 281 ms ] threadIs there a better link for the title or a better title for the link?
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.
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.
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.
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.
Complaints like this always mystify me. Would things be better if what you describe wasn't the case?
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.
I've been working on react-native recently, and this is by far the most difficult "framework" (or system, or library, or whatever else you want to call it) i've ever had to work with regarding dependencies.
Every. single. change. breaks. And it seems to have deep dependencies on exact versions of many other tools, and changing them causes all kinds of hell. It's awful, and it's what I see as "dependency hell". We are like 5 patch versions behind latest right now, but every other patch version between ours and current either won't build on one platform, won't start due to mismatched dependencies, requires an alpha version of react proper, or breaks all of our tests.
But before that i've worked on at least a dozen mid-sized+ node and browser based projects, and i've never had major issues with upgrades. For the most part they work if you stay within patch or minor versions, and even major upgrades only really hurt if you are impacted by the breakage, which in my experience is pretty rare (just looking at one monorepo-style project that has about 150 direct dependencies, i would probably spend about 2 hours a month on keeping them up to date, and just for fun, i went back to a commit from 3 years ago just now, and it still installs and runs fine.
If you stick to documented features, don't try to abuse or be clever with interfaces that aren't well defined, wrap any "iffy" libraries in your own interfaces to make switching or re-implementing them easier, and overall vet your deps a bit before installing them, it's pretty smooth sailing.
2008 BrowserJS still works in today's browsers.
2012 NodeJS code still works today (look at this v0.10.48 NodeJS docs for example: https://nodejs.org/docs/latest-v0.10.x/api/http.html )
The nature of JS is that there are very few breaking changes allowed from an end-user perspective even between major versions.
(6 months regular release support, 18 months active LTS, 12 months maintenance LTS)
For details, see https://nodesource.com/blog/understanding-how-node-js-releas....
https://auth0.com/blog/nodejs-10-new-changes-deprecations/
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.
* 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.
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...
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.