Having just passed my two-year anniversary at NodeSource, I took some time to reflect on the hundreds of conversations I’ve had with people who use Node.js.

In these discussions, it was evident that every individual’s use case, every team’s applications, every organization’s approach is different. They share some of the same tools, sure, but the JavaScript and Node.js ecosystems are so vast, and touch so many parts of the software development lifecycle, that no two uses of Node.js are identical.

Even when Node.js usage patterns are carried over from one company to another by a developer who helps introduce and champion the platform, those patterns are adapted and new patterns develop and evolve naturally to address the unique technical needs across the organization. This evolution manifest anywhere from the front-end toolchain, to novel approaches to scaffolding out server-side applications, to rapid iteration for prototyping, to building out custom monitoring tooling for DevOps teams.

Node.js can fit in everywhere within an organization. There are many cases where other tooling or platforms may offer an advantage, but virtually every organization–from hottest startup to the oldest enterprise–can and will find a use case for Node.js.

Because of the dynamic approach, I’ve personally noticed a pattern that we either haven’t fully addressed or we just don’t talk about. The broader ecosystem never just talks about Node.js anymore. We always talk about Node.js and... something else.

I’ve been thinking about this for the past six months or so, after a discussion with Tracy Lee about Node.js and Angular, and still we’ve not had an informed and public discourse about it. My goal in writing this article is to begin to engage the Node.js community and the broader JavaScript ecosystem in the discussion, giving some framing I’ve personally gained over the two years I’ve been working as a Developer Advocate and contributing to the Node.js project on daily basis.

The Age of "Node.js and…"

We’ve come to a point when Node.js is so ubiquitous that it’s become an accepted, invisible element of the development workflow. It’s not the only platform, but it is a universal platform.

Nearly every conversation I've had with Node.js users does not actually focus on what Node.js itself can do – instead, the focus is on the tooling, products, and ecosystems that have built themselves on top of Node.js as a platform.

For example: a startup may talk about Node.js and React for server-side rendering applications; an enterprise corporation may discuss using Node.js with Kubernetes and Docker for orchestrating Node.js-based microservices to scale up and down deployments dynamically; an individual developer may speak about how Node.js can be used for Serverless functions as a cost-effective and extremely efficient method of building applications.

In every case, we’re never just talking about Node.js.

I like to think of this shift in mindset as the introduction of the age of "Node.js and…" to us, as developers – which marks the need for a massive change in how the Node.js Community to approaches addressing the ecosystem’s rapid movement.

Defining "The Node.js Community"

To thrive in the age of "Node.js and…" we need to carefully define what “Community” and “Ecosystem” mean for the Node.js project. When we approach the idea of “community” as a project, everybody arrives with their own individual, unique, and subjective perspectives.

One person who’s been engaged with Node.js since 2010 may consider the maintainers of modules to be the core community of Node.js. Another who’s from a Ruby on Rails background, but has been in charge of building and deploying a suite of applications using Server-Side Rendering for the last six months, may consider the front-end stack and it’s dependencies (think Babel, webpack, React, Redux, etc.) the most central community.

To attempt to test the idea that everyone comes to defining what "The Node.js Community" is with their own subjective context, I reached out to a few individuals on the NodeSource team, each from a different background and tasked with entirely different roles inside the company – all focusing exclusively on Node.js. I asked each of them the exact same question:

What technologies are a part of the Node.js community?

They independently answered:

Back-end Engineer:

Every database for which there is a Node.js client, every service for which there is a Node.js library, and every OS that Node.js runs on.

Build Infrastructure Engineer

V8, C++, Git, c-ares, libuv, OpenSSL, ICU, Linux, OS X, Docker, npm, yarn

Services Engineer:

The MEAN stack, Front-end stacks, webpack, Grunt, Gulp, Git and GitHub. It extends from there but I’m reluctant to say they are a part, they are more a part of the development lifecycle of Node.js itself. For example, Docker, Kubernetes, AWS, GCP, CloudFlare, PostgreSQLs, Redis, and so on.

Registry Engineer:

The runtime and the more than 600,000 packages in npm.

Every answer they gave was directly relevant to their role and experiences with Node.js, with very little variance from that experience.

At the same time, I also reached out on Twitter with a question that was more focused on defining the groups of humans the that make up the Node.js community. I seeded the list with the set of roles that I first think of when I think of the Node.js community:

• Module maintainers
• Front-end developers
• Back-end developers
• DevOps
• CLI developers

Members of the Node.js community on Twitter then expanded upon this list with an interesting – and entirely distinct – set of responses, some of which represent groups I’d never considered before, but are easily defined as Node.js community:

• AI and Chatbot Developers
• Chrome Extension Developers
• Academic Researchers
• JavaScript/TypeScript users migrating from C#/Java
• Hardware Hackers
• Artists
• IoT Developers
• Physics/Game Developers
• Desktop Developers via Electron

Each of these responses came from individuals with different backgrounds and interests, and each answer aligned almost exactly with that set of context.

Defining "The Node.js Ecosystem"

The term "community" is so obviously different from “ecosystem” but in Node.js the line is… blurred. Who is a community member? Who is a member of the ecosystem? Where do the boundaries lie?

The broader developer ecosystem has ensured the continued existence of the blurred line. There are numerous distinct groups–distinct communities–who use Node.js, who care about it, who rely on it, but don’t necessarily self-identify as "Node.js developers"; using that identity to define who is or is not a member of the Node.js Community would ultimately exclude members of many of these groups, despite their clear interest in the project.

In the Node.js project itself, the Community Committee was formed with the explicit goal of growing and sustaining "the Node.js community". With that in mind, how does the Community Committee currently draw a line between “community” when compared to “ecosystem”? At present, it doesn’t. For the Community Committee, there’s not an explicit need to do so to accomplish their goals – and that’s okay.

That said, I do think there is a lot of value in understanding what "The Node.js Ecosystem" includes, and why understanding the definition of The Node.js Ecosystem is vitally important to the progress of Node.js in the age of “Node.js and…”.

My personal stab at a definition of what "The Node.js Ecosystem" goes something like this:

The Node.js Ecosystem includes the communities of any project, tool, framework, or application that depends on Node.js – and the people who work within them.

Looking at how different people defined what "The Node.js Community" is, we can recognize that every individual’s definition of “Community” falls into the broader definition of “Ecosystem”:

• Databases with Node.js clients? Yep!
• Services with Node.js SDKs? Totally.
• Supported operating systems? Of course.
• Native tooling required to build Node.js? Absolutely.
• Stacks focused on developer experience? Obviously.
• The front-end ecosystem? How could it not be!
• DevOps teams? Affirmative.
• Maintainers? Aye.
• Artists? Certainly.
• Extension builders? Naturally.

Communities – of which there are many – that use Node.js are all a part of The Node.js Ecosystem.

Why Understanding the Landscape is Important

So far I’ve gone to great lengths to explain the reasoning that individual definitions of "the Node.js Community" are subjective and the definition of “the Node.js Ecosystem” is broad and all-encompassing.

The distinction is important, and it’s something that we as and Ecosystem don’t talk about enough.

We talk about how Node.js is deployed for dozens of different use cases, has hundreds of thousands of modules that are part of the ecosystem, and is used by companies large and small.

We don’t really begin to scratch the surface of ensuring that we have accurate representation, experience, and understanding of each of the use cases represented within the Node.js ecosystem.

This is key to the Age of "Node.js and…".

Node.js as a technology is mature and has become a critical (if sometimes invisible) layer to the vast majority of technologies in its ecosystem. That said, one of the last communities to fully realize this is the Node.js core community itself.

We’re nearly a decade into the era of Node.js, and have pretty good processes for how to build, iterate, and maintain the core technology. We’re able to ship awesome new features both as a part of the Node.js platform and from the language specification that TC-39 is continuously working on, and we see interesting new contributors coming to the table to help improve the developer experience of the platform.

Nevertheless, we’ve become a bit tuned out of what the rest of the ecosystem–our ecosystem–is doing.

This isn’t to say that individuals in the project aren’t aware of the directions of their own communities, but we’re beginning to drift a bit away from the directions that the ecosystem as a whole are going.

The Next Decade: The Realization of "Node.js and..."

As I mentioned, Node.js is sometimes an invisible layer. To expand on that statement, I’d like to argue that Node.js has become an invisible layer within the modern web development toolkit. Regardless of what you’re building for the web, there’s a high probability that you’re using Node.js to do it at some point within your process.

The positive side of being invisible is that Node.js has–by all measures–become a successful and ubiquitous project. Virtually every "web developer" uses it, in addition to dozens of other kinds of developers; which is a tremendous accomplishment from a metrics point of view. Meanwhile, the negative side is that Node.js doesn’t get talked about as widely or as often as it used to, nor does it approach anywhere near the hype levels that the days’ “new hot thing” regularly attains. I’d argue, though, that this is a perceived negative and is really just a side effect of the positive. When something becomes ubiquitous, it’s not talked about as often as the things that complement it – when was the last time you praised indoor plumbing or the electric light bulb?

Embracing and acting on that sentiment – focusing on enabling the technologies, resources, and platforms that compliment Node.js and are members of its ecosystem – is going to be vital to the success and growth of Node.js over the next decade of its existence.

What do we Need to do?

At the project level, we’re going to need to take on the mindset of an Ecosystem-first approach and incorporate that more into the work we’re doing. There’s been some initial efforts around this, like the Modules Team, HTTP/2, CITGM, User Feedback, and others, but we’re going to need to continue to invest in integrating more deeply with projects by encouraging and enabling an open discourse with projects that are part of the Node.js Ecosystem.

At a community level, the broader Node.js community (including people who don’t consider themselves "Node.js developers") can let the project know what’s most important to them in terms of features in core or elsewhere within the project (there’s a lot to Node.js beyond Node.js core!) There are a variety of ways to do this, but engaging in any way helps ensure both stability of the platform and prioritization of the most important features to ensure community and project stability and growth.

At an ecosystem level, the only thing that needs to be done is to continue building – building new, cool, and interesting technologies that challenge what Node.js can do is vitally important to ensuring that Node.js is both well-rounded and performant. Totally unexpected and new use cases like Serverless and Machine Learning are some examples of this that push the boundaries of what you can do with Node.js yet are the best ways for the ecosystem to push back on Node.js for everyone’s benefit.

The project has gotten off to a good start with this in the creation of the Node.js Community Committee, which has begun to help bridge some of the gaps around this over the past year and a half. The community is often actively vocal when they strongly disagree with a direction the project is going–which does indeed affect change. The ecosystem keeps building new and incredible things on top of Node.js which help introduce new workflows for the project to act on. But we can always do more.

Above all else, we as distinct and unique communities need to continue pushing on the existing system. We need to push for better systems of communication and workflows inside of the project. We need to ensure that the communities’ interests are accurately and wholly represented. We need to ensure that the ecosystem is enabled to continue going down the path of mad science that turns into the mainstream for developers globally.

We need to push to ensure that a diverse set of the ecosystem is represented at all levels of interaction and that taking a "Node.js and…" mindset is the next step in the evolution of Node.js.

Postscript: Thanks 💚

I wanted to write up a quick "thank you" to the individuals from NodeSource and the community who helped out with this article. A massive shoutout to Adam Miller, Tracy Hinds, and Dominik Kundel who all offered input and did some level of review. Thanks to Mikeal Rogers for seeding a lot of the framing of these thoughts over the last few years and for offering to review this. Another massive thank you to both Tracy Hinds and Tracy Lee for discussing different things about Node.js and community that lead to entire sections of this article. And, of course, thanks to Amelia Mango for coming in with the clutch last minute review I needed to get this over the finish line.

Y'all are incredible ✨