- Node.js 14 adds several new features including better Internationalization support, diagnostic report, and async local storage APIs
- There are many ways to learn about and get involved with Node.js
- The OpenJS Foundation supports Node.js
- Node.js team members are actively involved with the TC39 ECMAScript standardization process
- Substantial care and effort go into every Node.js release
To learn more about the recent Node.js release and the Node.js project as a whole, we’ve invited Michael Dawson, active contributor to the Node.js project and chair of the Node.js Technical Steering Committee(TSC), and IBM Node.js community lead to join us.
InfoQ: Thanks for joining us Michael. Could you tell the InfoQ community a bit about your role in the Node.js project and how you first got involved with Node.js?
Michael Dawson: I first got involved in the community back in 2014 as our team worked to contribute our changes that added support for Linux on Power, Linux on Z and AIX to V8 and Node.js. It was a time of some tension at that point and I ended helping to work through the iojs split, formation of the Foundation and re-uniting the community along with other community members.
I’ve worked in different areas across the project in addition to core including build, n-api, diagnostics, package-maintenance, security, benchmarking. I’ve also been on the community Committee and Technical Steering Committee (TSC) for the last few years and am currently acting as the TSC Chair. I’m happy that my role as the IBM Community lead for Node.js gives me enough time to be involved across the project representing both the interests of the Node.js Project and IBM.
Dawson: One of the things that we established soon after I got involved was the Long Term Support (LTS) Process. The goal of the process was to balance the need/desire for a rapid pace of change while ensuring that those using Node.js in production would have stable releases.
We work to have low friction for new changes getting into master as well as people becoming contributors and being able to get work done. We want people to be empowered to move quickly on things that are routine while having the right checks/balances for more/larger contentious issues.
Changes flow into master and we have nightly builds where people can try them out. New changes in master which are SemVer minor or patch are then regularly flowed into the “Current release”. After being vetted in the Current release a subset of these new changes then flow back to the supported LTS lines. Current releases have a 6 month lifespan with even releases (12,14,16 etc.) being promoted to LTS and being supported for a further 30 months. As changes flow through the different release levels (master, current, LTS) we gain increasing confidence that they are ready for production.
Adding to the LTS process we work hard to build a good safety net through testing in our CI.
This approach lets us balance the desire for changes to flow in quickly, while at the same time ensuring stable and predictable release for end users.
InfoQ: So for someone building an application today, which version of Node.js should they use now in production? And when should they start thinking about migrating to version 14?
Dawson: If you are building an application today I would recommend using Node.js 12.x in production as the most recent LTS version. It will be supported until April 2022 (see https://github.com/nodejs/release for more details) giving you the longest runway before you will need to upgrade unless you want to take advantage of newer features. If you like to keep up to date or are currently running on Node.js 10.x I would suggest planning to upgrade early in the new year with preparation/testing starting late October. This will let you upgrade well in advance of the 10.x End of Life (EOL).
Dawson: I think the challenge is that it’s hard to get good performance without some level of integration and common platform and it’s also a lot of hard work to interact with the environment at the C/C++ level. If every JS framework had to worry about supporting different operating systems (windows, OSX,linux, etc.) and platforms (x86, Power, s390, Arm, etc.) they would move a lot slower and the level of performance would be much lower. Therefore, to be able to innovate quickly you want a platform that handles the lower level interaction for you. I think this is reflected in some of the discussion around new APIs we see come into core. One of the common reasons for adding an API to core versus as opposed to leaving it as an external module is that you can achieve better performance through the integration or avoid the operating system/platform complexities that would otherwise be encountered by the developer and users of the API.
Dawson: A standard library appeals to me personally based on past experience and some of the issues that come with having to use/install a relatively large number of modules from different authors in order to build most applications. However, in the discussions I’ve seen in the community that stray into related topics, there still seems to be more support for encouraging innovation in the ecosystem and getting the benefits of multiple options versus standardizing on one library. On the other hand there is a lot more discussion/recognition of the challenges related to maintaining the larger set of modules we depend on today. All to say it’s really hard to say if it will get traction at this point but either way it's probably a good time to have the discussion around it.
InfoQ: With the latest Node.js 14 release, what are some of the things that users should be most excited about with this release?
Dawson: I’m quite excited about the Diagnostic report becoming stable and the experimental Async Local Storage APIs. Tooling to help people investigate problems in production is a key aspect of any runtime and one where we continue to focus on. These are 2 good milestones that were part of the Node.js 14 release. I’m also happy to see that the full ICU (International Components for Unicode) data will be available when Node.js 14 is promoted to LTS in October.
Dawson: The major challenge was that Node.js already had a well established module system and that ESM was different in many important ways. Things like asynchronous loading versus synchronous loading leads to the potential for a lot of subtle interoperability problems. Unfortunately when the ESM spec was being put together the Node.js project was not very active in that process (or other standards either!). The result was some areas of conflict between the existing module system and long standing community expectations/usage and the spec as a reflection of what was a good fit for browsers. The modules team has done a good job of working through a large number of edge cases and finding approaches (and getting agreement for them which can be hard) that allow for reasonable interoperability while working to maintain compatibility with the spec.
Dawson: At this point I think the relationship is good and has grown over the last few years. At this point we have a number of people from the Node.js project participating in TC39. Myles Borins is part of the chair group, Jordan Harband is part of the editor group, and a number of members of the TSC + Collaborators have been involved in various capacities including Joyee Cheung, Joe Sepi, and Brad Farias. In addition people active in TC39 have also been engaging in the Node.js community, for example in the collaborator summits. For specifications that are going through the process today, tomorrow, I’m comfortable the Node.js project is engaged and that concerns would be heard/addressed.
Dawson: In terms of synchronization we don’t have regular interlocks or discussions. On the other hand Shelley Vohr who does a lot of the Electron integration is a Node.js collaborator and is on the Technical Steering Committee so there is a good/easy path for communication. One thing that we did put in place is the ABI (Application Binary Interface) version registry to help manage the sometimes different versions of Node.js that electron uses. This allows Electron to have a unique NODE_MODULES_VERSION.
InfoQ: If someone is interested in getting started with Node.js for the first time, where should they begin? Also with covid-19 the OpenJS Foundation’s OpenJS World event has moved online and is free as well as the collaborator summit. Are these good places to learn more about Node.js?
Dawson: The OpenJS Foundation event is a great place to learn more about Node.js, the project and the overall community. Given that it’s free this year and you don’t need to travel it’s a great opportunity if you’ve not been able to make it to in person events in the past. In terms of getting started with Node.js I think the best approach is to find a problem you want to solve (a small application, scripts you want to write etc.) and just jump in. There is nothing like a concrete problem to solve that can keep you going when you first start out with a new runtime. Once you’ve written some code you can then go back to the web and find articles related to larger scale deployments like running in the cloud or with kubernetes. Having written some code will help you with the fundamentals needed to understand the larger scale issues without necessarily having to build/deploy the larger application (although that's good too!)
InfoQ: What’s next for the Node.js project, both with bringing Node.js 14 to LTS and beyond version 14?
Dawson: It’s good that it's now just a routine to get to a new LTS release every October and that is a key part of what’s next. Continued stable and predictable releases, typically with improved performance.
In terms of larger features, the Node.js project does not have a formal roadmap so “What’s” next is often “What’s ready” when the next release is being cut. We do however, have longer term plans and initiatives. For example we have a set of strategic initiatives captured here. I’m also working to see if we can do a “next 10 years of Node.js” to help identify additional key initiatives (see).
From the IBM perspective we’ll continue to work on the Diagnostics front through the Diagnostic Working group, key structural components like N-API as well as the larger package ecosystem issues in the Package-maintenance working group.
InfoQ: The OpenJS foundation has a Node.js certification program. Could you tell us a bit about that, and what other things the foundation does to help with Node.js?
Dawson: The certification program allows a developer to demonstrate their knowledge of developing RESTful servers and services (JSNSD) or applications of any kind (JSNAD) to prospective employers. This can be particularly helpful if you don’t have a large number of years of experience and want another way to help make the case that you know Node.js. Other things that the Foundation helps the Node.js project with is marketing, legal and project resources. A few examples include, the travel fund, helping to get out the message when we have a new release, paying for the certificates we need to make releases on OSX, and providing the zoom account we use for meetings. If you think about the infrastructure you need to run a regular business, an open source project often needs many of the same things and the Foundation helps to support/pay for those when needed by the project. The travel fund is a great example, that without that support, we’d have a much harder time getting the number of collaborators to the collaborator summits as we’ve been able to.
InfoQ: How does someone get involved with the Node.js project? What skills are needed, what kind of help is useful?
Dawson: I always suggest a few things to people who ask about how to get involved.
- Go to Node Todo which is a great place to get help to work through a first contribution.
- Read through the docs, a fresh pair of eyes can spot things other people have missed and it’s an easier way to start contributing.
- Next consider helping with flaky tests or test coverage, that is a good way to get a deeper understanding and make tangible contributions without diving directly to changing the Node.js code base itself.
- Look for a match between your interests/skills and one of the Working groups/teams (Package-maintenance, release, N-API, build etc.) or strategic initiatives. Those often have an active group of Node.js collaborators and if you can find a match with what you’d be interested in working on it can be a great way to meet people who can help you get involved and find places you can contribute.
InfoQ: Thank you Michael for taking the time to tell InfoQ and our readers about Node.js!
About the Interviewee
Michael Dawson is an active contributor to the Node.js project and chair of the Node.js Technical Steering Committee(TSC). He contributes to a broad range of community efforts including platform support, build infrastructure, N-API, Release, as well as tools to help the community achieve quality with speed (ex: ci jobs, benchmarking and code coverage reporting). As IBM Node.js community lead, he works with IBM's internal teams to plan and facilitate their contributions to Node.js and v8 within the Node and Google communities.Past experience includes building IBM's Java runtime, building and operating client facing e-commerce applications, building PKI and symmetric based crypto solutions as well as a number of varied consulting engagements. In his spare time, he uses Node.js to automate his home and life for fun.