JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen

On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in.


[1:56] Is Node 8 just an update or is there more?


More than just an update
Two main points:
Improved Prana support
Native API
Native APIs are helpful for Native Add-ons. For both the consumer and the developer side.
Prior to update these Node Native modules ran in C++ and bound to specific to Node 8 APIs.
Causes these modules to be updated or reconciled every time these modules are rereleased.
Creates burden for module maintainers.
Creates friction in upgrading Node versions in production departments.
If you have a deployment depending on a certain Native module, some of the modules may not get updated in time when updating your Node versions. Keeping people from updating Node.
Creates compatibility issues with Node users not using Node 8
Experimental support for a Native layer in Node 8 to eliminate these issues as much as possible.
Important milestone for the module ecosystem.
You can write extensions for Node in C++ and it decouples V8 so you can use something else on the front.
Modules takes dependency on V8 API specific to a particular version. So if V8 changes your module will be extracted from that.
As a side benefit, you can have another VM to take advantage of that.
Major version upgrades mean updating Native modules and usually some of those modules haven’t updated to the newest version of Node and be complicated.
Deep dependency wise, about 30% depends on a Native module somewhere
In the future, with the Native API, you’ll be able to update Node without breaking modules.


[5:51] What kind of work went into this?


Most of the work was in C++
First thing that was done was, they looked at the top dependent Native modules in the ecosystem.
Looked for what kind of V8 exposure they had and cataloged it
Looked at how these APIs and what their purposes were
Looked for a way to extract them so that they are part of Node Core
Created neutral APIs, now part of the Node core.
All C APIs
Also has a C++ wrapper to improves usability of the API.


[7:17] What’s an example of what you can do with these APIs?


Native modules allows for tighter integration and better module performance
Specific APIs that you can use in V8 that isn’t available through JavaScript
If you have a C++ variable code and you want to expose a variable into JavaScript, that is V8 API note a Node 8 API
Having it bound directly to the VM was something they wanted for a long time
Google controls V8 and they bind to V8
Created a better relationship with Google starting in IOJS
Also worked with Microsoft with their Node Shocker work.
Same with SpiderMonkey
SpiderNode is in the works


[9:23] Have you guys done any testing for performance?


Some. There is a performance working group.
There is a need to stay on top of V8
V8 team has focused on new language features
Many features have been added over the years
Many didn’t come in optimized
The performance profile has changed with these features
If you’re using new language features, you will see a performance boost
In core, still tracking down code that was specific to the old optimizer and rewriting i to work the new optimizer
Turbo C compiler hasn’t landed yet, but is to come.
Will have a completely different performance profile
In most real world applications it will be faster
Waiting on the release to take a version of V8 to make it easier to upgrade features in the future


[11:28] Are the new features picked up from V8 or implemented in Node?


It’s all in V8
Better longterm support
Promises are made better in Node as a platform
Added new method called util.promisify()
Implementation comes from V8
Allows for more optimization for promises in Node core
Promise su