The State of Node.js 2025

So, yeah, me. Hi. Hello. A lot of things. You're probably using my software. Last year, you all downloaded my things 30 billion times from NPM, so, you know, don't attack me. So, okay, we're going to talk about two things. You very often see... this is one of my favorite slides, by the way. See these kind of statements that XYZ will destroy Node.js. This was fun. And that XY will flip the default backend runtime from Node.js. These happened. These are quotes.

Okay, so this talk is to answer one question to all of you. Is Node.js dead yet? Every single one tried to kill Node.js and, I don't know, is it still dead? Is dead? No, it's not. There's one secret, one really dark secret in technology and, like, everybody that tried to destroy some tech. Well, the first secret is that the technology that was born in 1959 is on the rise again. Do you know what it is? It's frigging COBOL. It's frigging COBOL, okay. To be clear, this is a career in that kind of things, okay.

So, also, jQuery recently released version 4 and it's still powering a good chunk, most of the web, as so far. And by the way, if you're still using jQuery 1, you have a problem. But a lot of people still are. So, okay, hi, Node.js, 16th birthday. Okay, so Node.js is one of the most popular technology according to Stack Overflow, recently overcome by React, but still up there. Also, unfortunately, these graphs are not there yet. The last one was from 2024, then this site died. But it's a good comparison of the size and growth of the NPM ecosystem versus the others. And it's, you know, NPM and Node is essentially two sides of the same coin.

And the NPM ecosystem did a phenomenal thing and is the most popular open source registry out there of things to download. Modular usage is growing more or less 50% every year and it doubles every two years. You're downloading a lot of modules, guys. I don't know. It's not going down, it's not slowing.

Some important stats is half of the downloads are header files. Do you know why? Why? What are header files? When you have a binary addon and you install a module from NPM, if you haven't run install the binary addon every single time, you are downloading the header files to compile that binary addon. It's done automatically for you, you have to do nothing. But every single time you do that, you compile some things, it downloads these header files. This is why it's so massively downloaded everywhere.

Also, you know, downloads from Node overall were 271 million downloads for Node.js in December 2024. And in May it was 375 million downloads per month. So, apparently you guys are still downloading Node even more. I have no clue why. You keep downloading new versions. Well, I have some numbers here. First of all, you're not updating Node.js. So, we keep releasing new versions of Node and you're still downloading it. In fact, Node 12 is growing. Look, look, look, over there. Oh, sorry. Why? What is it? Come on. Okay. And here we go. Node 12 over there, do you see the red one? It's rising. This, I have no clue. Yeah. Anyway, you're not updating Node. Okay? Why are you not updating it? So, first of all, quick reminder. A quick check for the audience.

How many of you are using Node 12? Okay. The downloads. Okay. No, I'm joking. So, Node 18 has gone out of support in April. A huge amount of people are still using Node 18. In fact, we are going back here is very funnily is still downloaded 50 million times. You know? In May. It's insane. Okay? 50 million times in May and it's out of support. What are you going to do about it, guys? Sorry.

Node 20 is in maintenance mode. What does it mean? It's not getting new features. It's only getting bug fixes, it's getting, you know, security fixes. But, you know, on a best effort situation. Node 22 is what's called active LTS. And active LTS means it's getting new features every single time. We're going to talk a little bit more about the new features that are coming and we have backported. In October, it will go into maintenance mode. And Node 24 is going to be the new active LTS. Please, guys, update.

Something very important and you can see it here is that you a lot of people skip a version. Okay? So, a lot of teams keep a version. This is Node 16, okay, going down. Still downloaded, I don't know, 30 million times per month. I have no, like, sorry, guys, I'm flabbergasted. Okay? But a lot of teams are, you see that a lot of people are jumping from Node 16 to Node 20 straight away. Okay? And, but the number of downloads are, as I'm saying, growing and growing and growing and growing. The activity in the organization is growing.

The activity in the organization is growing. Okay? A lot of pull requests open, a lot of PRs open in the project. A lot of things happening. A lot of new people showing up and contributing. In fact, there's been a lot of, more or less, the activities going very well. A number of incoming pull requests is stable but there is still a lot of new feature, a lot of new things being worked on.

Something very important is about updates, okay, and security. So, the Node project works very hard to keep you all safe and fix, give you a nice security release every quarter. Do you like our security releases? Maybe. Probably not. Okay? We don't like them either. But it's, you know, we live in this world. We receive a lot and a lot of submissions. Okay? Something about between 20 and 30 per month, which is a lot. Imagine that you need, for each one of them you need to triage them privately and 90% are completely bogus.

And it's a lot of work that happens underneath the scene and it's a lot, you know, there is a threat model, please read it, a lot of them are valid, but you know. And we usually respond very quickly. So, we respond in less than a day. It's very active. And the time for triaging, so we respond and say, hi, start sending some questions, and then we do the final triaging in a day or so, in a few days, which is pretty good. Some of these was funded by a fund called Alpha Omega. I don't know if you're familiar with it, but you should probably should. It's great.

And it gives us some funding to streamline our security and have some people working on it. This is the only amount of money that Node.js adds. The funding was cut in half in 2025, reducing from 300 to 150. Coming to Node, required ESM is now available and works out of the box. .mjs is no longer needed, making the process simpler. TypeScript runs out of the box and is expected to be stable by Node 24 LTS.

Marco Ippolito implemented TypeScript and will discuss it further in the next talk. A change in V8 improved open telemetry tracing performance by about 7%. It enhances Async local storage speed significantly, making operations faster. The goal is to unflag TypeScript in Node 24 and possibly Node 22, a significant milestone for Node development.

The performance improvements in V8 positively impact tracing efficiency and Async operations. The funding decrease challenges Node.js, emphasizing the reliance on volunteers and passion. Required ESM simplifies loading processes, and the removal of .mjs reduces complexity in script execution. TypeScript's integration and planned stability for Node 24 LTS mark crucial advancements in Node.js development.

Also, .mjs is not needed anymore because nobody liked the Michael Jackson script. You can run it, and it just works. It will warn you that loading files this way might be slower. TypeScript runs out of the box. Marco Ippolito implemented TypeScript and will discuss it further in the next talk.

They aim to unflag TypeScript in Node 24 and have it stable by Node 24 LTS, a crucial milestone. A V8 change improved open telemetry tracing performance by around 7%. Async local storage operations are significantly faster. The explicit resource management feature in Node 24 allows automatic deallocation for variables, enhancing resource cleanup.

The permission system in Node.js has been stabilized to enhance security. It enables process constraints on file system access. Companies concerned about security can utilize tutorials to control file system permissions effectively. The system ensures proper file system access restrictions for enhanced security.

So, a very important thing happened with a change in V8, allowing a 7% improvement in open telemetry tracing performance. This enhancement also boosts the speed of Async local storage operations significantly. The explicit resource management feature in Node 24 automates deallocation for variables, ensuring proper resource cleanup.

We have stabilized the permission system in Node.js to bolster security. This system enables process limitations on file system access, providing tutorials for effective file system permission control. Additionally, networking capabilities will be incorporated soon.

Node.js relies on volunteers for its open governance model. Collaborators, as volunteers, govern the Node.js project, contributing without direct payment from the foundation. This model underlines the necessity for community involvement and contributions to the Node.js project.

It already works for timers, and other APIs on Node 24, but we are in the plan on adding this through all of them. Why this is useful? Because you can essentially, you will be able to use a file or use a stream, and those will be automatically deallocated and cleaned up correctly, especially if there is a native resource underneath. And it's also worth sync and Async. So, it's pretty great.

We stabilized the permission system. A lot of companies have been complaining about Node.js security, but the permission system is there. It allows you to constrain the part of the file system that your process can read and write. Additionally, tutorials are available to guide users in effective permission control. Networking capabilities will be added soon to enhance the overall functionality of Node.js.

Node.js relies on volunteers, collaborators, and governance for its operation. The project emphasizes the importance of community involvement and contributions from volunteers. The open governance model of Node.js ensures that collaborators, who are volunteers, govern the project without direct payment from the foundation. The technical steering committee, comprising over 100 individuals, plays a crucial role in setting release dates, maintaining quality, and resolving disagreements within the project.

Node.js needs volunteers. Node.js needs collaborators. It's the key part there is Node. We need people. Why? Because Node.js is an open governance model. And what does this mean? Well, we are part of a foundation, and there is nobody that is actually paid by the foundation to work on the project, okay? So, minus the security things. What does it mean? It means that Node.js is governed by its collaborators, and they contribute to the Node.js project. They are all volunteers. Some of them are volunteered by their company that gives you, you know, a salary for putting bread on the table. But the project is run by the collaborators.

What does the technical steering committee do? The technical steering committee is the governing body, and it always acts when the collaborators do not agree. There are 100 plus people. What's the chances of 100 plus people not agreeing? So, anyway, not necessarily that. Usually, people can find a compromise, okay? But genetically, this is the situation. We said, so, the technical steering committee, which I'm part of, set release dates, quality, and so on and so forth. The bits is when we disagree, the TSC votes. Okay, that's what we do. When there is a disagreement, we vote. That's it. So, this means that no one can control Node, okay? There is only a very limited number of people of the same company, the Node.js TSC. So, essentially, it means that Node.js cannot be controlled. And usually, each collaborator has to compromise to achieve its objectives and goals.

It's very important to note, open governance, there is no benevolent dictator. There is no, we tried all of that. We tried companies, they have a benevolent dictator, nothing worked for Node, okay? So, it's a community project. What does it mean is there is nobody to fix your bugs, okay? So, if you have a bug, probably the best person to fix your bug is you. Let me clarify that. We could fix some bugs. You can probably try to find a collaborator to help you fix the bug, but most of the time, you are responsible for your own. There are a few companies out there that can help you if you want to contact them, but, generically, the project is not fixing your bugs.

So, okay, I have three more minutes and I have a few gifts for you. The first gift is an e-book that we wrote is free. You can download and scan. You pay with your e-mail, 250 pages or something of goodness. So, we condense a bunch of stuff, you can download. It's free, okay? It's, but you will get e-mails. Thank you. It's offered by Platformatic, my company. So, that's it, okay?

Then I wanted to talk a little bit about some stuff that I released last year, which is an application server for Node.js, which makes your applications enterprise-grade out of the box. What it does, it runs your application in streamlined multi-threading, running multiple Node.js applications within the same thread, within the same process using threading, and standardizing probe, logs, metrics, open telemetry, and so on and so forth. These allowed us to do a few good things. Well, we made it run PHP. I don't know if you saw the announcement, but I'm going to recap.

You can, thanks to our new tech, Platformatic Tech, we are able to run PHP inside Node.js as a native add-on on a separate thread. So, you could essentially create a single process in which you have your next JS application and your PHP application. Now, I'm going to speed run an installation of WordPress here. So, we have just downloaded WordPress, and I'm starting WordPress using npm start. All of these works essentially inside Node.js thanks to a native add-on that is compiled. This is a full version of PHP 8.4 compiled down. You just need to essentially configure and install it, and it will just essentially work.

How does it work? It runs PHP on a separate thread, and in that way, it can block and do all those things. Also, you can use it to run it alongside your, I don't know, next JS application or either front and stuff, which is pretty cool. And you, here, I missed speed running it because I didn't have enough time. So, anyway, what do we do? We need to configure both apps. So, we have the next JS application here and the PHP application. So, we have a PHP and we build. We need to build next. Okay. And yay, fantastic. Build, and we build. Here you go. Multiple mistakes, you see. I'm human. And running it and npm starting it, and you see here is the full thing for PHP. It needs a little bit of tweaks for parameters and WordPress, and then next JS is there. Now, how do you connect next JS with PHP? You just need to change your page and, you know, specify a different URL and then we can do. What we can do is we can have a full headless PHP rendered by a full blog rendered by next. Cool. Thank you very much. I have the book. If you need any help with Node.js, please reach out. Thank you. Thank you so much, Mateo.

So, the first question here is what happened in 2022 with the peak in module count on npm? Spam. Good answer. All right. Next question. Do you think the billions of Node.js downloads indicate some huge inefficiency? Could the majority of automated builds and test runners be driving these numbers? There is definitely a good chunk that is done by CI systems, okay? A lot of them are done in that way. But also it's also telling us that people are testing their libraries and applications against those systems. So, they are still a proxy. Like, the total number might be skewed, but the fact that people are still testing their systems against Node 12 or Node 8, you know, this is a long conversation. Okay? It's a problem.

Now, consider this problem that we, the Node team, I was not involved in it, ended up having to completely redo the infrastructure for running those downloads, because essentially if our download site was going down, we will have people with pitchforks on Twitter and so on in like five minutes. And we had essentially to completely rearchitect the full system. It's now being powered by Cloudflare workers and a global distribution network based on their R1 database, because it was literally not, like, publishing a new release would wreck the CDN and stuff and it would cause problems. So, we had to redo the full thing. Wow.

All right. Next question here. If Node.js were being invented today, what's one major architectural or other decision you think would be done differently? Oh, I have infinite amount. Like, Node.js grows too fast, too quickly. We all know that. Okay? And there is a lot of, there are a lot of things in there that we cannot change and fix, due to some very powerful module, popular module, being, using internals. And this is part of the problem. Okay? Like, part of the problem is a lot of internals are accessible and a lot of early users, early popular modules, started to monkeypatch internals to get there where they wanted. And what happened was that we cannot change some of those internals, because otherwise we break everybody. And so, what I would not do is, what I would change is mostly how HTTP is implemented and how the HTTP server is done. I want to change that at some point in the future, if I could. I'm trying to do some lobbying against a very popular framework called Express. You know Express, right? To stop monkeypatching Node. And so, once that stops, we can probably get it done. Nice. This is a good one.

Sometimes, contributing to Node.js code is hard. Do you think those frictions will be reduced, do you think those frictions will reduce the possibilities for new features? So, okay. Contribute to Node.js. I presume Node.js core. Okay, Node.js itself. Yes and no. Like, some features can be done, implemented in JavaScript, and it's quite feasible to do that. Some other features will require some C++ skills, which you could learn, but it's a little bit more of a gap. And this has always been there, and the biggest gap has always been C++, not really anything else. So, it does not change, it does not stop the project from growing. People learning C++ have learned C++. So, if you want, it's possible. It's just the way of life, unfortunately.

What can you say about people comparing Node.js with Deno? Oh, I really like Deno. It's a great architecture. It's probably how a lot of things about Node will be done today, in a lot of ways. In others, they recently ended up re-implementing or lifting a lot of the Node.js source code to re-implement the Node.js compatibility. So, the goal, I think, is to have most of Node.js apps run straightforward to them. And yeah, that's my take. I have no other take. Yeah, and somebody also asked about Bunn as well in another question, so we might as well throw that one in there if you have any extras. Again, the game here for them is about Node compatibility. They are two bot startups, and they are great, and I hope them all the best success. I hope they don't destroy Node.

What are the reasons behind running PHP in Node.js? So, the main reason is a lot of people have been using a lot of PHP systems out there. You can probably ask, and there are still some. And a lot of them want to keep them running and keep them as in the so-called headless mode. I don't know if you've seen this term connected a lot of times.

And a lot of them want to keep them running and keep them as in the so-called headless mode. I don't know if you've seen this term connected a lot of times. The first time I was working in such an application was in, I think, 2017 with a very popular newspaper using, you know, WordPress for editing, and then wanted to use React for their front end. It's pretty good. It's a pretty good architecture and that works very well. There's a lot of software built in PHP these days. That problem is not going away anytime soon. Tons, yeah.

What do you think, why is module resolution Node still widely used over Node.next or Bundler in the TS config? Because people don't update their software and their stack. It's the genetic bit. They coded that in, maybe, that is a little bit later. It's not 2015. Maybe that is 2017 or 2019. And then I've also seen some very down leveling to ES5 in some of those TS configs. So you should probably take a look at your TS config, your tooling toolchain, and then start modernizing that. It requires care.

Is there any work being done around native testing, like test code in the same file as runtime code, or module mocking? This is possible already. We ship Node column test out there. It does work. You could potentially use it in the same file. I probably would not recommend it in any form or fashion, but if that's your poison, you pick your poison. You do you. Module mocking is supported on ESM and I think also CommonJS too. It just works as well. So yes, those features are already available. Nice.

Here's an interesting one. Will there ever be an official replacement for NPM? So, okay, let's talk about this. This is important. We have the NPM registry and the NPM client. The NPM registry contains the list of all the modules you download every day. I don't think there will ever be a replacement for the registry. On the client side, this is a good question. I don't think so, personally, because it's still the official client for the registry. I hope there will be movement on that side from NPM and GitHub, from GitHub itself, that is the maintainer and steward of the registry and the official client. But it needs to come from them, essentially. All right.

If people are updating Node.js every two LTS versions, is it worth it to update the schedule around that? No, because it's still picking up a lot of usage and we can actually do a lot of things there. So we want to ship new features and let you test new features as quickly as possible and also find the bugs as quickly as possible. If we only update it every two years, you will be losing some of the security things. So we have only more or less a three year-ish time window for open SSL support. After the three years window, we don't get open SSL updates and security fixes anymore, and that's why we need to do essentially this rolling thing every year. So you get updated open SSL and so on. If we did it every two years, basically, there will be a moment where there will only be a version being supported. Very small moment when the two things will be completely out of sync and that would be, I think, problematic for a lot of users. Awesome.

Well, thank you so much, Matteo. This has been awesome. Thank you. And that was great. Thank you. Bye.