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


Interview Popular open-source JavaScript runtime Node.js hit version 15 last week, and to bring us up to date we spoke to Michael Dawson, Red Hat Node.js lead, who is also chair of the Node.js Technical Steering Committee and Community Director of the OpenJS Foundation.

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 ERR_UNHANDLED_REJECTION.

"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

Node.js uses the same JavaScript engine as the Chromium project, called V8. This has its own native API, and developers may want to call this API from native add-ons for performance or to support additional features. "Back in 2016 we started working on what we call N-API, which is an API that that helps you build your native add-ons," Dawson explained.

Michael Dawson, Red Hat Node.js lead, chair of the Node.js Technical Steering Committee and Community Director of the OpenJS Foundation

Michael Dawson

"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?

The Node team is aware of Deno, a new server-side JavaScript platform co-authored by Ryan Dahl, who also created Node.js and now says that Deno fixes many of its problems. "All projects are going to end up with some legacy, it's the price of success that you can't go back and just change all those things," said Dawson. "A number of things in Deno are interesting and have been discussed within the project for years."

JavaScript code

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.

TypeScript is another key feature in Deno, which has built-in support for this popular alternative to JavaScript. Should Node have tighter integration with TypeScript, or does it introduce friction because of the extra compilation step it imposes?

"It's still pretty strongly two different camps," said Dawson. "There's the people who love TypeScript. If you've come from, say, a Java development background, it seems more familiar, it gives you a little bit more comfort. On the other hand, there's a large number of people in the JavaScript community who feel that the advantage of JavaScript and Node has been the ability to move quickly, iterate quickly and that friction really slows you down.

"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." ®


Biting the hand that feeds IT © 1998–2020