Node v9.8.0(nodejs.org)
nodejs.org
Node v9.8.0
https://nodejs.org/en/blog/release/v9.8.0/
50 comments
Slightly problematically - a lot of AWS's default Node infrastructure seems to still be using Node v4.
I assume they'll be updating it but that was true as of last week.
I assume they'll be updating it but that was true as of last week.
Too bad half the modules on npm wont work in 5+ And I don't blame people for not fixing breaking changes every third month. Ohh the module has less then 100 collaborators !? I better not use it then. Ohh it has not been updated within the last month ? Better not use it. The cool project that required beta version of node, now half a year later it's too old.
The best part of nodej is code reuse. Not code re-write! /rant
I use node 5+ since like forever. Next to every npm-module works for me. And if not, a node downgrade does not help.
I think that person meant npm 5 perhaps?
Which still isn't true, so I have no idea what they are talking about.
The problem is with the ABI and libuv. It's very hard to debug and fix the problems if you do not know C++
I do a lot of systems programming in NodeJS and are depending on those modules to access platform API's.
I do a lot of systems programming in NodeJS and are depending on those modules to access platform API's.
That’s surely a problem with C++ and OS tooling rather than npm tho...?
The problem is NodeJS semver major, eg breaking changes. And the nodejs modules stop working. And the high frequency of semver major makes it hard to keep up. If you are lucky the module is maintained at all that is.
[deleted]
A bit overblown, don't you think?
Anybody know when AWS Lambda will update their node runtime to latest LTS?
I’m curious what prevents those updates from happening faster...
I’m curious what prevents those updates from happening faster...
really looking out for this one! Using async/await in lambda would really help in my specific use case.
Just finished benchmarking this for a key workload in our build process. It's 3% faster than Node 8.x for us. But node-chakracore (the Microsoft runtime) 8.9.4 was 11% faster -- we are considering switching to that.
Assuming you're testing on Windows, node-chakracore is currently released as a beta, so Node 10 is probably the more appropriate comparison.
Can you share more details on this build workload? Like what does it do? what packages it uses ? etc.
Can you even measure 3% accurately and repeatedly?
> --inspect-brk now works properly for esmodules
When ES Modules landed in Node? How do they work? .mjs? :(
When ES Modules landed in Node? How do they work? .mjs? :(
They're available right now behind the flag `--experimental-modules`, and planned to be released without a flag in node 10.
And yes, still requires .mjs unfortunately.
https://nodejs.org/api/esm.html https://medium.com/the-node-js-collection/an-update-on-es6-m...
And yes, still requires .mjs unfortunately.
https://nodejs.org/api/esm.html https://medium.com/the-node-js-collection/an-update-on-es6-m...
I sincerely hope they remove .mjs requirement. Lets not have io.js division again, all the frontend libraries are on npm and newer ones tend to use es2015 modules!
What I suspect is going to happen is that frontend people will just shrug and adopt the .mjs extension. Browsers don't care what extension you use as long as the mime type sent by the server indicates that the file is javascript.
Not exactly the entire story. Browsers don't care about the extension, true, but they still need to know whether to parse the script as a module or not, by using: <script type="module">
Hey this is cool! How come I haven't heard of <script type="module"> before.
I guess I should seriously subscribe to a newsletter or something.
I guess I should seriously subscribe to a newsletter or something.
How is this going to work with the gazillion existing NPM packages and projects using Babel?
Right now you just require a Babel runtime first, then use import for everything else not caring what type of modules they are. The acceptance test for proper module support in Node.js should simply have been that you can remove the Babel wrapper in an existing project that uses imports instead of requires :(
Right now you just require a Babel runtime first, then use import for everything else not caring what type of modules they are. The acceptance test for proper module support in Node.js should simply have been that you can remove the Babel wrapper in an existing project that uses imports instead of requires :(
I doubt it - so long as @std/esm exists, I imagine that will continue to be the low-friction approach, especially considering how much better it is at CJS interop, supporting __dirname, __filename, etc.
I'd like to learn Node.js from scratch, but would like to learn on the latest version.. any resources anyone knows for this?
I'd say it really depends on what you want to to do in the next months !
Node can be a very productive environment for web APIs and applications (with great frameworks such as Express or Koa and amazing libraries such as PassportJS) and I personally use it this way 95% of my time.
But in its heart lies the event-loop, the streams, the pipes, its functional programming capabilities and all of this makes it a simple and very pleasant way to script, transform, to build algorithms or neural networks!
Plus javascript is becoming a very friendly language as Node and ES6 leveled the browser inconsistencies that turned web developers crazy in the past.
Just start writing applications and dig into the API documentation. This is how I learned Node.
I will say having a background in systems programming and scripting for filesystems is hugely beneficial. I am just a pansy JavaScript developer, so I had to figure this all out to be better at writing Node apps.
I will also say current versions of Node are massively backwards compatible. Very little of old features have been deprecated or killed out. This is all spelled out in the API docs.
Perhaps the hardest part to learning Node is wrapping your mind around asychronous operations. Don't spend time with the synchronous methods if an asynchronous method is available.
I will say having a background in systems programming and scripting for filesystems is hugely beneficial. I am just a pansy JavaScript developer, so I had to figure this all out to be better at writing Node apps.
I will also say current versions of Node are massively backwards compatible. Very little of old features have been deprecated or killed out. This is all spelled out in the API docs.
Perhaps the hardest part to learning Node is wrapping your mind around asychronous operations. Don't spend time with the synchronous methods if an asynchronous method is available.
You're absolutely right about the backward compatibility. If you're still learning and not on a production server, no need to rush on the latest release.
I'd argue an easy way into NodeJS is to introduce yourself by one of the most popular frameworks, what they do, so you'll see how they benefit from NodeJS and where its strengths lie.
I'd recommend ExpressJS or Meteor.
You should use https://runkit.com (disclaimer: I work at RunKit). It lets you try node in your browser, and you can easily switch to any version of node, and additionally we've pre-installed every package.
Well the basic concepts are the same. I don't think many of the major concepts such as EventEmitters and Streams have changed. I'm pretty sure most tutorials you will find should still work but I may be wrong
Depending on where you are, you might be able to find a NodeSchool group to help you get started: https://nodeschool.io/
Wes Bos has some good courses that takes you up through ES6 which will be pretty close to the latest node version
Chance are, by the time you've learned anything, the wheel will have turned once again, ages will have come and passed, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the age that gave it birth comes again.
In the JS world, back or front-end, this process seems to be accelerating at a terrifying rate, heading to a singularity where all the accumulated brainpower of the human race is devoted to trying to keep up with the latest way that npm or node or babel or webpack has broken shit that previously worked.
In the JS world, back or front-end, this process seems to be accelerating at a terrifying rate, heading to a singularity where all the accumulated brainpower of the human race is devoted to trying to keep up with the latest way that npm or node or babel or webpack has broken shit that previously worked.
Cute, but wrong. The basic architecture of Node has not changed, and the core modules are largely the same as they have been for years.
The question "How does Node work and how can I leverage it" (which is what GP is asking) is the same as it was a few years ago.
The question "How does Node work and how can I leverage it" (which is what GP is asking) is the same as it was a few years ago.
Literally none of this is true.
If you haven't upgraded Node in the last two years, this is the last call.