I'd like to use this as an opportunity to remind everyone that Node.js v4 is going to be dead in about a month (support for it has ended long time ago, and now it's the end of extended support).
If you haven't upgraded Node in the last two years, this is the last call.
That he is working somewhere without the foresight to upgrade their apps off a legacy, unsupported and potentially insecure versions of node, or that he himself can't summon willpower to do it I guess.
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
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.
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">
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 :(
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.
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.
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
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.
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.
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.
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.
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.
50 comments
[ 5.9 ms ] story [ 44.4 ms ] threadIf you haven't upgraded Node in the last two years, this is the last call.
Sucks to be him either way.
I assume they'll be updating it but that was true as of last week.
I do a lot of systems programming in NodeJS and are depending on those modules to access platform API's.
When ES Modules landed in Node? How do they work? .mjs? :(
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 guess I should seriously subscribe to a newsletter or something.
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 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.
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.
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.
I’m curious what prevents those updates from happening faster...