Node.js 15: What's new, what's coming, and keeping pace with Deno. 'We're not going to reinvent' module ecosystem
Michael Dawson, chair of Node.js Technical Steering Committee, talks to The Reg
So what's new in Node.js 15? One thing is what happens when an async function fails and throws an error outside a catch block. In the past, Node gives an
UnhandledPromiseRejectionWarning but the process exits with a success code. This has changed so that it will now fail with
"Unhandled rejections can lead to problems that are very difficult to figure out," said Dawson. "This will let developers find them much more easily because your Node project will stop running right, and that's something that you're going to notice."
The trade-off is that an application that has been stable for years might now fall over. "That's why we were careful to make sure that it's very easy to add a very small amount of code and get back up and running," said Dawson.
Native modules, Node and WebAssembly
"Previously you had to use the V8 APIs directly, so in every release of Node which includes a new version of V8, developers would have to update their code. N-API provides a stable API that you can compile against."
Version 15 has an updated N-API. "It brings a couple more methods that help you work with buffers," Dawson said. "N-API doesn't have 100 per cent coverage of the V8 APIs, more like 80-90 per cent. So this release brings some progress, though we never plan to provide complete coverage."
There are other options for native code, including FFI (Foreign Function Interface) and WebAssembly. "WebAssembly isn't necessarily a replacement for N-API," Dawson said. "There's different use cases where you'd want to use one versus the other. WebAssembly provides a strong sandbox, but along with that comes some limitations."
In future, he would like to see the compiler handle some of these choices. "You could have code that you can compile to WebAssembly if it uses the subset of the APIs," he said, "or if it doesn't, you compile it to N-API, and that changes over time."
Deno – a better Node than Node? TypeScript?
Node.js creator delivers Deno 1.0, a new runtime that fixes 'design mistakes in Node'READ MORE
That said, he is not convinced by all the Deno changes. Use of promise-based APIs throughout is one thing Dahl says is desirable, but Dawson told us: "The Node project had introduced some things like
util.promisify() that lets you use the existing APIs with promises, but promises don't tend to be as efficient in a lot of the cases, so we're not going to move over."
Another issue is the security model, where Deno has a strong sandbox and claims to be "secure by default".
"There is a balance between added complexity and value," said Dawson. "A lot of the discussion ends up with, for practical applications you've got to turn all that stuff off. What I'm interested in is if Deno can show that's not the case and that people actually use it in real life.
"We could do that but it doesn't seem like it's going to add that much value to the end user. We also get into discussions about 'Should you do that enforcement at the Docker level?'
"It's great to have another project experimenting, but so far we haven't had the compelling evidence that it's going to add enough value for us to do."
What about the way modules are loaded, where Deno has a reviewed, audited system? "The module ecosystem for Node has been really successful so I don't think we're going to be too quick to completely reinvent that," Dawson told us.
"Should Node be doing something to provide an improved TypeScript experience? Should we actually pull in the types into Node and manage them? The answer there seems to be no, even from the TypeScript advocates. They were raising issues that would cause in terms of how they maintain if there was a problem in the typing after releasing a new version of Node. If there's things we can do that make sense for TypeScript we should consider those. So far it seems to work out just fine."
Core versus modules and the next 10 years
The Node community has embarked on a "next 10 years" debate in order to determine the direction of the project. One of the issues is what belongs in core Node and what belongs in modules. For example, should WebSockets support be in core?
"We have this constant discussion about what makes sense to be in core versus in modules," said Dawson. With a module, developers have to validate the code quality, see if it is maintained, that the author is trustworthy, whereas "something that's in core you can be pretty confident that it's had a lot of eyes look at it, that we're going to be very careful about keeping it stable.
"That drives the desire to have more things in core. On the other side, the more things we put in core, the more maintenance that we have to do, so we need to be careful that we don't take too much in. That balance is what we're constantly walking. Some people are saying WebSockets are a very important piece of single page applications and it would be easier for people if they were in core. I don't think we have consensus that it should or should not, but the 10 years effort is to try and build a more forward-looking view of what needs to be in Node."
Talking of modules, can anything be done to make them safer, when developers pull in dependency after dependency? Metadata is part of the answer, Dawson told us.
"The [module] maintainers are struggling," he said. "They may have written a module, it was a hobby they did on a weekend, now they've got 20,000,000 downloads and the people who are using it have expectations which are more than what is appropriate for something that they're getting for free. We've worked on something that we call package support which is adding extra metadata to the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there a company? Is it part of a foundation?
"We've built a tool which helps you validate, with an option that says just list me out all the support. Module owners, please help us by adding that data in. You should be able to run a tool that pulls out the information to help you better understand the modules you're using.
"Open source is free to get, but I wouldn't say free to use. You either need to get involved in the projects to help keep them going, or maybe work with a company like Red Hat who provides support for those modules. Just using them and assuming everything is going to be OK is not good business practice. You should look at your risk, understand that risk, and invest to manage that risk in an appropriate level. I don't think there's any silver bullet." ®