Node.js in 2026 with Rafael Gonzaga

0:00JavaScript has grown far beyond the browser. It now powers millions of back-end systems, APIs, and cloud services through Node.js, which is one of the most widely deployed runtimes on the planet. Keeping such a critical piece of infrastructure fast, secure, and stable is a massive engineering challenge, and the work behind it is often invisible. Rafael Gonzaga is a principal open-source engineer at NodeSource and a member of the Node.js Technical Steering Committee. He spent years digging into the performance and security layers of Node's core, helping shape the direction of the runtime itself.

0:38Raphael joins the show to talk about the state of Node.js performance, how benchmarking really works, the balance between speed and stability, and what it means to contribute to one of the world's most important open-source projects. This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O 'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling.

1:21Find Josh on BlueSky, Fostadon, and.com as Joshua K. Goldberg.

1:39with me today is Rafael Gonzaga, Principal Open Source Engineer at NodeSource. Rafael, welcome to Software Engineering Daily. Hello. Thank you. I'm happy to be here. Well, we're excited to have you. You do a lot of great stuff with Node.js and performance and userland libraries. But before we get into all that, how did you get into coding? Well, it started since I was a teenager. I always been in computers since I was young. I played a lot of games, but my father is blind. And back in the time, he couldn't make a few things on the computer because of the disability. And then I started creating a visual or kind of talkback.

2:18I tried to do that at least. And then my journey in the computer science started. I tried to make it happen with Python, Python 2 back in the time. I don't remember. I couldn't make it work, but then I learned, okay, this is how I could make a calculator. This is how I could make things to work. So I started there, but until now I couldn't make it. But there are plenty of good apps nowadays that he uses, and I'm still helping with some plugins and things like that. So do you have experience then with accessibility technology and writing things for folks who are, for example, blind? To be honest, my focus is on backend.

2:58So accessibility on web browsers is not my thing. But I know exactly the problem that it causes because very often my father calls me. OK, Facebook is not working anymore. They changed something. Can you help me? And then I need to write a Chrome extension that will replace the element to the old way that he's used to get and make that happen. But on frontend, I'm not that person. But you do work in an area that sometimes folks erroneously call frontend. So I think we should take a moment here to recognize that JavaScript is not a purely frontend technology. It's very possible to spend much of your career in, say, Node.js and JavaScript and be entirely backend.

3:41What do you think of the areas that your code has touched or the stuff that people use your areas for? Well, I always loved low-level programming. So I started with Python, but then I suddenly jumped to C and C++. I learned most of the things outside of university. By the way, I haven't completed my degree, so I don't have a degree nowadays. And then during the process, I learned many, many languages. I came from Elixir, Erlang, I went to PHP, C Sharp. but I still learned I have still working on personal projects with C++ and C. And then I found that, okay, there's JavaScript. People use JavaScript on Frontend, but I don't like Frontend too much.

4:23Then I saw, okay, people were running JavaScript in backend. I tried, okay, let's see how it works. And my first attempt with Node.js was in a hackathon a long, long time ago. And then I could make an HTTP server. And then I saw, okay, that's nice. Let me see how it was created. And then I saw the GitHub repository and then, okay, they use C++, so I could help in that part. Then I started looking to it, but I didn't make the contribution back in the time. But yeah. So how did you go from starting to look at Node to becoming a member of the Node Technical Steering Committee? Okay. I have started on Fastify, an HTTP framework.

5:03When I was working as a soft engineer in a company that was about to switch other PHP projects to Node.js, they were looking to a microservice approach. And then I was responsible to make that migration. So I was investigating, OK, we are about to use Node.js, but let me make some tests to see how well scale this new platform. Then I saw some HTTP frameworks like Express, and a lot of people were advocating about Express, and all the resources you find in the internet, they use Express. But I made some benchmarks, and Express was not fast as I thought it could be. And then I was looking, okay, let me see if there are other HTTP frameworks, because Express is not official from the Node.js team, right?

5:53It's a library, as well as Fastify. And then I tried Fastify and I saw the benchmarks page from that. And I saw, okay, this is nice. The results is exactly what I was expecting. But I found a bug during the process and I decided, okay, let me create that request. That shouldn't be a GIF code. I wrote the request. It was accepted. And then I saw, okay, the community was very welcome. And I decided to keep contributing to Fastify. Then I met Matteo, Matteo Colina, one of the Fastify creators during the process that told me, do you want to apply to a position at Neoform? I said, yes. I made the test, which is very curious because something got wrong in the process.

6:42And then I did the test for a senior front-end engineer and I passed, but I haven't worked as a front-end engineer at all, but I passed anyway. Then after passing, I got migrated to Mateo's team. And then I got some tickets to work on Node.js core. And one of my first requests to Node.js was fixing a memory leak on a Windows 2012 server, 32 bits. And I spent, I don't know, two weeks or three weeks working on that. And it was very hard because I had to SSH into a machine which was far away from me. And I was testing, debugging memory lakes, and I could fix that bug. After that, I learned a lot about Node.js Core.

7:30And then I started doing a lot of stuff. And I got nominated to Node.js Core. And then almost three years ago, I got nominated to Node.js TSC. What does it mean for someone to be on the TSC for Node? It's very important to be part or to have a voice in technical discussions. But to be honest, if you are a Node.js collaborator or if you are outside of Node.js team, you can still advocate, you can still share your opinion. It's more about being more proactive on helping new members or discussing new features and having more context about Node.js in general. So if someone attempts to include, okay, let's reshape Node.js.

8:19So let's remove C++ and move that to Rust. Normally, the TST team are the set of people that will say if that's possible or not. And also in case of discussions, they have a vote if we should do it or not. So it's important, but it shouldn't be something that should guide people to get that role, to be honest. It's more about having a voice. I think voice is not the correct term here, because technically the TSE was created just to guide the project, but we shouldn't have more power than any other contributor. That's what I'm trying to say. A TSE member shouldn't be anything different from an OJS core collaborator.

9:04Anything that a core collaborator does, a TSE can do, and vice versa. So I don't know if I could explain that well, But yeah, that's the idea. It's kind of amorphous being a technical steering committee member on a project that doesn't have one single tracking company or one single charter. But your area has typically been performance. And you've written quite a lot about Node performance. How do you see that evolving these days? Currently, I work on Node.js security and performance. Performance, I normally do it because all my studies, my research are in performance. However, I've been paid to work full-time on Node.js to focus on security.

9:45So I have these two fields. For performance, I have been monitoring Node.js performance for quite a while. I have a lot of projects around that. And recently, I'm leading the performance initiative of Node.js. However, due to a restricted bandwidth, I don't have much time to work on that because I'm not paid full-time on performance, but in security. I normally write some reports like the state of Node.js performance, and the Node.js have been evolving a lot, mostly due to V8 improvements. So V8 is doing a very good job in JavaScript. So some performance improvement came from V8 per se, and some of them is because Node.js is migrating most of its API from JavaScript to C++.

10:32In the past, we had a lot of discussions if we should write APIs in C++ or JavaScript. And the reason that some of them were writing in JavaScript is because it's way easier to get contributors for JavaScript than C++. So, okay, some API, let's write it in JavaScript because it's easy to get maintenance. But then we saw, okay, for these specific APIs, JavaScript will be a bottleneck. So let's move that to the C++ part of Node.js. Then we moved and then we saw, okay, we got a significant performance improvement. And if you compare the Node.js startup, for instance, we got a significant improvement and that applies to Lambda providers.

11:18If you are using Lambda on AWS or VeriCell, even CloudFare workers, you see that it's very important for them to have a very fast cold start. But I would say that those new runtimes like Ban and Dino, they have moved Node.js to get a different point of view in terms of performance. We were more stable in the past, not releasing many features and being more assertive. But now we have switched a bit our focus to hear more about the community. If community wants some modules like SQLite, let's do that. It doesn't need to be so sacrificing for maintainers. So we have that. And we have a more strict focus on performance.

12:02So we are actively monitoring benchmarks, micro benchmarks of Node.js. And to be honest, it's very hard to write benchmarks in JavaScript in general because of V8. V8 can be very tricky. Most of the times is smarter than you. And if you are writing a micro benchmark, possibly you are looking to the wrong metric. So it's very hard to make some comparisons because some API might be fast on your machine or in your workload. And with a different workload or running that for more time, it will cause more de-optimizations, optimizations or garbage collectors, and then you see a different performance.

12:39But yeah, I would say that Node.js is way faster than two years ago. I want to walk through a couple of scenarios with you just to help flesh out what you're saying. Do you recall a performance optimization you attempted at Node that did not work out after running all those optimizations and benchmarks? Yes, there are plenty of them, to be honest. At Node, there is a working group called Node.js Performance, which stores most of the issues that people find about regressions in Node.js in general. Some of them we were investigating, I believe it was from Node.js 18 to Node.js 20 or a specific version of Node.js 20, which MacLav compiler inside V8 was introduced and enabled by default.

13:27After that, we have received some issues saying, okay, my microbenchmark is telling me that my code is 50 % slower than in a previous version of Node.js. Then we came up to investigate. And the reason is that Maglev was, if you run that piece of microbenchmark for a short period of time, Maglev was being introduced. And this was causing some slow operations. But it turns out that if you run that with a production workload and running with a reasonable amount of time, McLev was being called, but then it was moved to the TurboFun, which is the optimized bytecode of V8. And then the result or the performance of the code was similar.

14:14So for short scripts, that might be a performance bottleneck, but for long-life ATP servers, the performance was the same. So it's very tricky to measure micro benchmarks in JavaScript because you might be measuring a no operation because V8 optimizes your code away. You might be measuring a non-production or an unrealistic workload because you will never run that function many times as you are measuring. And some of them, for instance, in a specific version of V8, if you were converting a string to an integer using parseInt in comparison to a plussino, the plussino was, I don't know, 10 times faster than parseInt in some V8 versions.

15:02I have shared that on Twitter. I have a repository that monitors all those micro operations. And I have also wrote about that. And it was fixed by V8. And it turns out that most of the cases, if you attempt to switch all parsing into plus sino, it will only give you 0.0005 milliseconds of performance improvement. So most of the time, it doesn't worth the change. So it's tricky. Capital One's tech team isn't just talking about multi-agentic AI. They already deployed one. It's called Chat Concierge and is simplifying car shopping. Using self-reflection and layered reasoning with live API checks.

15:46It doesn't just help buyers find a car they love. It helps schedule a test drive, get pre-approved for financing, and estimate trade-in value. Advanced, intuitive, and deployed. That's how they stack. That's technology at Capital One. One of the open source projects I work on, someone spent, I think it was about 2 ,500 words trying to explain to us why we needed to switch from one library to another. that would save about, don't quote me on this, about 104 bytes of Node module size and about a fraction of a hundredth of a hundredth of a hundredth of a second of runtime improvement at the beginning.

16:17But at the same time, as I'm sure you're going to say within the next 10 minutes, sometimes these optimizations really do result in user-in-line improvements, where something that's a fraction of a second faster compounded over time really is better. So how do we know when we're looking at, say, optimizations in Node or in user-in-line libraries, when is it worth it to make that performance investment? Okay. It's very important to have baseline. So if you're trying to optimize your code, you need to have a benchmark. So if you have most of people that use Node.js, they use as an HTTP server. So measure how your routes are responding or how they are performing.

16:57If you are getting, I don't know, 10 ,000 requests per second, if you are getting 100 ,000 requests per second, measure CPU utilization, measure memory during workload, during a benchmark tool. When a benchmark tool runs, like WRK2 or AutoCannon or Apache benchmark, it doesn't really matter. Actually, it matters, and I can explain a bit more later. But create a baseline. This is the state of art of my HTTP server. Then you start measuring. You can't optimize things without measuring things first. Otherwise, you fall into a trick role where you are spending a significant amount of time to get just a small milliseconds of improvement, as you said.

17:39But there are a lot of improvements you can do, mainly when you are comparing some HTTP frameworks. Like most of you use Express because Express is spread everywhere. but what most of you don't know is that if you switch from express to fastify you get a lot of performance i'm not saying that because i'm part of the fast fighting i'm also part of the express performance team and what i can say that fastify in the last versions it's way faster than in the i don't know a year ago so always measure fastify is still as far as i know the fastest framework in terms of stability and performance out there for Node.js.

18:25And more importantly, make sure that everything that you write to the logs, for instance, logs is a huge problem. A lot of people lose a lot of performance by just choosing the wrong log library. People are using console.log, which is a huge problem. If you're doing that, please stop. People are using, for instance, Winston. done, I wrote an article called The Cost of Logging, I believe in 2022, and it is still very popular and still applicable. As far as I know, the fastest logging library out there is Pinot.js. The reason for that is that Pinot was writing in a way that it can create a QE of messages and will not block the event loop when writing to the terminal.

19:15I wrote in depth about that in that article, so I suggest people to check that. It's very easy to find. And Pinot.js also uses Sonic Boom as a dependency, which is very important to make Pinot.js fast. So by choosing the right HTTP framework and the right logging library, I'm pretty sure your app will be way fast than nowadays. One of the advantages, as I understand it, of writing things in user land, like for example, first Express and then Fastify, is that allows users to iterate an experiment. But at the end of the day, some of the things you've alluded to, such as console.log being slow, are part of Node core and therefore the default that a lot of people go with.

19:55What would it take for Node itself to have an equivalent to an Express or Fastify or PNOT.js in core? Okay. The PNOT.js in core is to, we are discussing that, to be honest. So that might happen. Yes, a lot of people ask me why simply Node.js folks can rewrite the HTTP module to make it similar to Fastify and Fast as Fastify. And the reason for that is first one is maintenance. So Fastify, they have a huge thing maintaining that. And for Node.js, if you move things to Node.js, it's expected that you get less contributors working on a specific module because it's way hard to understand Node.js source code and fastify.

20:38The second one is that we can't break the world. Node.js is used by tons of devices and even releasing things as major, server major, which is expecting to break, we can't touch very hard on NTP modules because this will migrate people away from Node.js. If you look to the recent Node.js downloads dashboard, you see that a lot of people are stuck on Node.js 12 just because of breaking change. They don't know how to migrate. It's very hard for them to migrate. And those breaking changes are very crucial for them to stick on an end-of-life version. And this is a problem because when you stay in an end-of-life version of Node.js, you are not safe.

21:27There are plenty of vulnerabilities that affect you. And I also wrote a talk, I have delivered a talk called Five Ways You Could Have a Hacked Node.js, where I exposed some vulnerabilities that Node.js have fixed. And if you are using an outdated version of Node.js, possibly this will happen to you. And that's it. I mean, we can make some improvements to HTTP module, but we can't change it too much. How it was designed is crucial and its legacy. First, it's very hard to change. And second, changing that means that you are prone to break a lot of people. So you have two conflicting desires and needs here.

22:08One is you want to keep things stable because breaking changes hurt the community's ability to migrate, but you also want to have modern APIs and improvements. So how do you strike that balance? How do you know what's of valid or correct breaking change to make? Most of the features, they are behind flags, behind enabling flags. For instance, we brought the permission model. Permission model is a feature where when you enable that, the Node.js will restrict access to file system, to network, to V8, to V8 inspector protocol, child process worker threads. So all of these will be restricted whenever you pass dash dash permission when you use Node.js.

22:47This is a secure measure. And people ask me, why not enable that by default? The reason is that, first, it will break all the scripts out there, so people will never be able to migrate. People do not read changelogs. They just don't want to read that, or for some of them, it's hard. Some of them use Node.js behind the scenes. So, for instance, if you are using Next.js, you are using Node.js behind the scenes, And in some situations, you don't have the Node.js command out there. It's behind next run or something like that. So this will break frameworks and frameworks will need to upgrade. And then users will need to upgrade their frameworks versions to fix that.

23:31So it creates a kind of chain of breakage that will reach out to the end users. And this will be very difficult for them to migrate. So frameworks will be mad with us. Users will be mad with us. And most of the cases, if we enable the permission model by the full, a lot of people will just pass disabled permission because they don't care about that. So we decide, okay, if people, they care about performance, they will opt in. It would be much easier if we were writing Node.js from scratch. So let's say that we are releasing Node.js 2.0. Possibly those features will be enabled by the full because we will teach people this is how this Node.js was designed.

24:13If you want to use Node.js, that's how you go. But since Node.js is still the same, people are just using NVM to upgrade and they don't expect this new design, this new structure. They don't want to learn Node.js again. We can't do that. Yeah, it's also on, what's the latest major version at time of recording? 24.10 or so, or we're not quite at the 2.0 level anymore. Yes, that's correct. I'm working on Node.js 25.0 that will go out in two days. Oh, well, that's exciting. What are the major changes or features for 25? So one thing important about server major releases, a lot of people believe that server major are the most exciting releases of packages, of runtime platforms like Node.js, but turns out that it's very, very boring.

25:02Server Minors goes to server miners releases. Performance improvements, they most of the time are categorized as SemperMiner or SemperPatch, which means that it's very likely that Node.js 24.10 will be way more exciting than 25.0, because 25.0 only contains breaking changes. And for Node.js 25.0, we will have the upgrade version of V8 to the version 14.1, which will bring the major JSON stringify performance improvement. So if you look to the V8.dev, they have created a blog post about how they have made JSON stringify fast. And with this version of Node.js, it will bring the V8 version that includes that performance improvement.

25:50We will have a new built-in inside integer 8 array. It's for base 64 or hexadecimal conversion. Web assembly and GIT pipeline optimizations. We are also enabling adding a new feature to the permission model, which is the dash dash allow net. So network will be restricted whenever you use the permission model on Node.js 25. But other than that, we don't have a lot of features coming in. Most of them, they are breaking changes or considered breaking changes. So if you are using the permission model Node.js 24, it's likely that you get affected by Node.js 25 with this new network restriction. We are unflagging the experimental web storage.

26:34So web storage will be enabled by default on Node.js. And we are deprecating and removing a lot of APIs. APIs that was runtime deprecated, they were removed on Node.js 25. and some of them will be runtime deprecated on Node.js 25. So if your console, whenever you run Node.js and some API is emitting a warning to you that this will be soon removed, possibly Node.js 25 will break you. So upgrade that. That is exciting, removal of dead code. Does that attach node performance, download size, and so on at all? Yes, I mean, we'll remove code that needs maintenance. So for us, maintainers, it's very good to remove code.

27:17Is your AI model taking weeks to train? Or is it too slow for real-time inference? Fixedars AI Booster is the acceleration platform that solves both. AI Booster automatically analyzes and optimizes your entire AI pipeline. The result? Dramatically faster training. Up to 5 times faster. And compute costs slashed by up to 80%. Trusted by major companies including Sony Honda Mobility. Stop waiting on your hardware. Visit FixedStars.com to learn how. I want to take us a bit back to the second of two scenarios. We talked about a performance optimization attempt that ended up showing, well, not always optimal.

27:57Is there an upcoming one or a recent change you've made that you're excited about for a performance that did work out? There are one that the pre-request is to open. I wrote that with Robert. We'll bring a significant performance improvement to the HTTP module of Node.js. We talked about that and then I remembered. But it's an opt-in feature. So we are releasing that to not break people. It's a new flag. Whenever you create an HTTP server, there is an optimize empty request option. Basically, if you are relying on the REST pattern, which is get request should not have a body. Head request should not have a body.