BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview with Node.js Technical Steering Committee Chair

Interview with Node.js Technical Steering Committee Chair

Key Takeaways

  • 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

Node.js is a server and command-line environment for JavaScript built on the V8 JavaScript engine. The recent Node.js 14 release introduces improvements in Diagnostic Reporting, Internationalization, ES module loading, and an experimental Web Assembly System Interface.

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. 

InfoQ: For any of our readers that might not be familiar with JavaScript, what’s your description of what Node.js is?

Dawson: Node.js is what lets you run JavaScript on a server instead of in a browser. To a large extent the JavaScript specification does not address interaction with the “environment” , things like reading/writing files, sockets, etc. Node.js provides the API’s needed by your JavaScript code to interact with the environment in a server environment just like the browser does on the client side.  The result is a small, fast to startup runtime which is async oriented. It’s well suited for asynchronous applications like REST APIs as well coordinating a number of different requests needed to satisfy a client request. Along with that it has the additional benefit that developers can write in the same language on both the front end (running in the browser) as well as the back end (running in Node.js).  The result is both good productivity for developers and great performance when used in the right context.

InfoQ: I think it’s worth adding that web and JavaScript developers who don’t touch the server environment still likely use Node.js every day as it’s also widely adopted for command-line utilities, build tools like webpack, and more. Node.js has certainly come a long way since the original announcement at JSConf.eu in November, 2009! After some early growing pains, Node.js runs very smoothly with predictable releases. Could you describe some of the things about the way Node.js is run that make the project successful?

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

InfoQ: It is in my opinion pretty remarkable that Node.js is as widely adopted and used as it is. Not that I ever doubted its quality, but mostly because the JavaScript ecosystem historically seems to never want to align or standardize around just one solution to a problem. What do you think led to Node.js being different in this regard compared to say JS frameworks, testing tools, and event language variants?

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.

InfoQ: Do you think we’ll see traction in the near future on any of the efforts towards a standard library mechanism for JavaScript? I’ve certainly wanted to see progress on something like this for nearly 15 years!

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.

InfoQ: It really is amazing how long it has taken for Internationalization support to arrive in JavaScript. We actually tackled some of this work in Dojo as far back as 2005, and people never realize how complex this can be. I’m super excited to see this work landing in the language and in Node.js! Similarly, The road to module support in JavaScript has certainly been a long one. When we started Dojo in 2004 we started with a very primitive synchronous module loading system and syntax, and later worked on AMD. ES Modules (ESM) are in many ways a significant improvement, mostly in that after several follow-on additions they seem to provide most module loading features and they work everywhere. What are some of the challenges Node.js has had to overcome to support ESM, and are there any limitations they introduce for Node.js users?

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. 

InfoQ: I think the ES Module system is really interesting in that it should do away with the habit of a separate module or package per function since you can now just import what you need, which is especially important for client-side performance optimization. But I know this certainly hasn’t made life easy for implementing the specification. Dynamic imports were a largely missing feature in the first version of ESM. Given some of these challenges between specification and implementation, what’s the relationship like between Node.js and TC39, the working group that evolves the ECMAScript/ JavaScript standard? 

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.

InfoQ: Electron is an interesting project, in that it combines Node.js and Chromium to effectively provide a client and server in a single application environment, allowing developers to leverage JavaScript for building desktop applications. How do the Node.js and Electron teams collaborate to keep versions of Node.js synchronized?

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.  

Skills of all kinds are useful. JavaScript of course but also C/C++ as much of the runtime is written in C/C++. In addition, system management skills are needed on the build team, writing skills are needed for docs and evangelism/marketing. Really almost all kinds of skills are needed. In terms of the help that’s most helpful it’s the kind that comes along with the solution in addition to the suggestion of something that should be done. Since the work is done by volunteers, suggestions and feedback are great but that takes finding a volunteer that will do the implementation. A Pull Request that proposes a fix is most often going to be more helpful than a suggestion that somebody fix a problem :).

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.

Rate this Article

Adoption
Style

BT