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

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna HenningsenOn 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 https://www.npmjs.com/package/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 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey- https://github.com/mozilla/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,...