Podcast Summary: Node.js in 2026 with Rafael Gonzaga

Podcast: Software Engineering Daily
Date: December 23, 2025
Host: Josh Goldberg
Guest: Rafael Gonzaga, Principal Open Source Engineer at NodeSource, Node.js TSC member

Episode Overview

This episode explores the evolving landscape of Node.js through the insights and experience of Rafael Gonzaga. As a core contributor and leader on both performance and security fronts, Rafael discusses Node.js's progress in performance, benchmarking challenges, userland vs. core decisions, and the community dynamics of major open-source infrastructure. The conversation is technical, practical, and reveals internal reasoning behind key Node.js choices, as well as opportunities for new contributors.

Key Discussion Points & Insights

1. Rafael’s Journey Into Coding and Node.js

• Inspired by his father’s visual impairment to develop accessibility plugins.
• Early experiments with Python; gravitated to backend and low-level coding (C, Elixir, PHP, Erlang).
• Discovered Node.js while migrating PHP projects to a microservices back end.
• Entry into open source: Fixed a memory leak bug in Node.js on Windows (03:47-07:40).
• Progressed from Fastify contributor to Node.js TSC member.

"I have always loved low level programming ... Then I saw, okay, people were running JavaScript in backend. I tried, okay, let's see how it works ... Then I saw the GitHub repository and then okay, they use C so I could help in that part."
— Rafael Gonzaga [03:47]

2. Role and Nature of the Node.js Technical Steering Committee (TSC)

• TSC's power is guidance, not hierarchy.
• Facilitates technical discussions and mediates on major potential changes (e.g., language swaps).
• Every contributor's voice matters, TSC membership isn't about power over others (07:44-09:15).

"A TSC member shouldn't be anything different from a Node JS core collaborator. Anything that a core collaborator does, a TSC can do, and vice versa."
— Rafael Gonzaga [08:36]

3. Current State & Evolution of Node.js Performance

• Node.js performance has greatly improved in recent years, thanks to V8 updates and selective migration of APIs from JavaScript to C (09:29-12:43).
• Shift in core philosophy to balance stability with agility due to competition (Bun, Deno).
• Node.js takes community signals more seriously: more focus on performance and user-requested modules.

"Node JS is way faster than two years ago."
— Rafael Gonzaga [12:37]

4. Realities and Pitfalls of Benchmarking Node.js

• Micro-benchmarks in JavaScript/V8 are tricky and easily mislead; context and input shape performance.
• Stories of optimizations that failed or were misleading due to benchmarking pitfalls.
• Performance improvements can be statistically insignificant—importance of deep, statistically robust benchmarks (12:43-15:35).

"It's very hard to make some comparisons because some API might be fast on your machine ... and with a different workload ... it will cause more de optimizations."
— Rafael Gonzaga [11:35]

5. Approach to Performance Optimization & When It’s Worth It

• Importance of establishing baselines before optimizing (16:38-19:39).
• Dramatic improvements are possible by swapping frameworks (Express → Fastify, logging libraries).
• Console.log is a major performance problem; advocates for using Pinó (Pino) as a logging library.
• Always profile, measure, and use specialized tools.

"If you are doing that [using console.log for logging], please stop."
— Rafael Gonzaga [18:34]

6. Why Core Doesn’t Just “Copy” the Fastest Libraries

• Constraints: Breaking changes would disrupt millions, legacy compatibility is critical (20:01-22:05).
• Node.js central modules have a stringent bar for change due to global dependency.
• Example: Many are stuck on old Node.js versions due to breaking changes and migration pain.
• New features (e.g., permission model) opt-in by flag to avoid mass breakage.

"We can't break the word. Node js is used by tons of devices ... How it was designed is crucial and its legacy first is very hard to change."
— Rafael Gonzaga [21:36]

7. Node.js 25.0—Major Features and Release Philosophy

• Major releases are actually focused mostly on breaking changes; features and performance come via minor releases (24:44-27:04).
• Node 25.0 will bring V8 14.1 (major speedup for JSON.stringify), permission model enhancements, new APIs, and removal of deprecated features.

"It's very likely that Node JS 24.10 will be way more exciting than 25.0 ... 25.0 only contains breaking changes."
— Rafael Gonzaga [24:58]

8. High-Impact Performance Work: The “Optimize Empty Requests” Flag

• Opt-in HTTP server flag to double throughput for certain REST patterns (28:02-30:32).
• Example: Benchmark went from ~32,000 to ~69,500 requests/second.
• Not default due to backward compatibility, but likely to influence future default settings after community signals.

"We are more than doubling down the performance ... But this is specific to the get and head requests."
— Rafael Gonzaga [29:48]

9. The Challenge and Science of Benchmark Validation

• Node’s internal performance CI suite takes up to 84 hours (!). Benchmarks are run 30 times before and after changes for statistical significance (31:23-35:18).
• Null hypothesis testing and normal distribution plotting are standard.
• Example: Even “shooting a gun in a datacenter” can inadvertently skew results—real-world benchmarking is hard (35:24-37:15).

"To run a full Node JS benchmark CI, it takes 84 hours."
— Rafael Gonzaga [32:23]

10. Annual “State of Node.js Performance” Reports

• Rafael authors statistical reports each year matching Node.js versions to performance in real-world use (37:15-42:12).
• Tracks regressions, upgrades to dependencies (V8, OpenSSL), and user impact.
• Reports split for TL;DR audience and detail/benchmark nerds alike.

"This report contains all the information and all the resources you need to know before upgrading ... or to diagnose your Grafana dashboard."
— Rafael Gonzaga [41:32]

11. About NodeSource and nSolid

• NodeSource: Build APM (nSolid) focused on high-perf, low-overhead production monitoring (42:43-44:34).
• nSolid is a fork of Node.js instrumented for high-efficiency performance and security tracing.
• Some nSolid improvements are upstreamed to Node.js core, others are proprietary for business value.

12. Practical Node.js Performance Tips

• Use Fastify for HTTP servers; use proper route definitions.
• Always use high-performance logging (e.g., Pinó), avoid console.log.
• Optimize object manipulation: prefer assigning undefined to deleting properties for V8 hidden class performance (45:02-48:18).
• Measure everything: sockets, syscalls, dependency vulnerabilities.
• Minimize dependencies, use built-in modules where possible.
• Tool: npx is-my-node-vulnerable for Node.js version health.

13. On Lock Files

• No strong opinion as a library author (48:18-48:56).
• Most libraries don’t include lock files to allow dependency upgrades.

"[For libraries] We don't release log files because people can upgrade that."
— Rafael Gonzaga [48:46]

14. On Contributing to Node.js & Community Involvement

• Rafael runs livestreams of contributions and Node.js release work to mentor others (49:10-49:44).
• At least 10 people have contributed to Node.js via his streams.
• Recommends contributing to open source for career growth, learning, and community.

"My career would be way boring if I didn't contribute to open source because it opened so many challenges for me that I could learn a lot."
— Rafael Gonzaga [50:13]

15. Personal Passions and Closing

• Outside tech: plays soccer (“football”) 3 times per week; supports Santos and Manchester United (51:35-52:36).
• Contact: Best via Node.js mentoring channels on X (Twitter), Discord, or Slack.

Notable Quotes (w/ Timestamps)

• "Node JS is way faster than two years ago."
  — Rafael Gonzaga [12:37]

• "If you are doing that [using console.log], please stop."
  — Rafael Gonzaga [18:34]

• "To run a full Node JS benchmark CI, it takes 84 hours."
  — Rafael Gonzaga [32:23]

• "My career would be way boring if I didn't contribute to open source because it opened so many challenges for me that I could learn a lot."
  — Rafael Gonzaga [50:13]

Timestamps for Important Segments

| Timestamp | Segment/Topic | |------------|-----------------------------------------------------| | 01:46-03:47| Rafael's introduction and early tech background | | 04:53-07:40| Path from Fastify to Node.js Technical Committee | | 09:29-12:43| Node.js performance evolution | | 12:43-15:35| Benchmarking: pitfalls and lessons | | 16:38-19:39| When is optimization worth it? | | 20:01-22:05| Why Node core can't just "be Fastify or Pinot" | | 24:44-27:04| Node.js 25.0 release: breaking changes vs features | | 28:02-30:32| Doubling HTTP throughput: the empty request flag | | 31:23-37:15| Benchmarking science: repetitions, stats, CI time | | 37:24-42:12| Annual State of Node.js Performance reports | | 42:43-44:34| About NodeSource and nSolid | | 45:02-48:18| Practical performance advice (logging, objects, etc)| | 49:10-49:44| Contributing: livestreams and onboarding | | 50:13-51:19| Personal reflections on open source | | 51:35-52:36| Rafael’s sports & teams | | 53:02 | How to reach Rafael |

Conclusion

This episode delivers a nuanced, insider’s account of Node.js’s ongoing technical and community evolution straight from the core. Rafael emphasizes practical, measurable approaches to performance, the real-world constraints of maintaining a global runtime, and the openness of Node’s community for new contributors. Both the technical depth and community orientation shine, making the episode relevant for Node.js users, maintainers, and open-source newcomers alike.

For in-depth Node.js performance insights and how to get involved, follow Rafael on X (Twitter), or join community channels on Discord and Slack.