Program

The mission of the Web Interoperable Runtimes Technical Committee (WinterTC) at ECMA is the promotion of interoperability between all JavaScript runtimes, regardless of what role they play on the web. A key part of that effort is defining the minimum common API surface that developers in the ecosystem can expect runtimes to provide.

WinterTC started with an effort to define the common subset of Web platform APIs. Now the focus is switching to the common subset of Node.js compatibility APIs that all runtimes should support.

Improving the autocomplete in MongoDB's database CLI seemed like a great idea. But when the team tried to flip the feature flag, things quickly started to go sideways: a story of memory leaks, bugs that touch the very core of JavaScript as a language, and hard-learned lessons about testing and performance.

Most Node.js performance advice stops at "use async/await" and "run a profiler." This talk picks up where that ends. Drawing from years of shipping a high-throughput broadcast platform, we'll cover the patterns that actually move the needle: allocation-free hot paths, sync fast paths where async is 190× slower, cooperative scheduling, sqlite, and scaling with Workers.

You'll leave with a mental model of where Node.js spends its time and a handful of building blocks to drop into your own code.

Most Node.js memory discussions stop at "the V8 heap." Production systems are rarely that simple. A Node.js process uses multiple memory systems simultaneously: JavaScript objects on the V8 heap, native memory allocated by Node.js and its dependencies, memory used by Buffers and streams, and memory consumed by the operating system and external resources.

Understanding the interaction between these layers becomes essential when applications start processing large datasets, streaming files, integrating with native libraries, or mysteriously crashing with out-of-memory errors while the heap looks perfectly healthy.

We'll cover how V8 organizes and garbage-collects the JavaScript heap, why Buffers live outside the heap and can exhaust memory, native allocations inside Node.js and third-party dependencies, how streams and backpressure affect memory usage, why some leaks never appear in heap snapshots, and practical techniques for profiling production memory issues.

At the Node.js Collaboration Summit 2024, a proposal for a new HTTP stack built around Web Standards such as Fetch, Request, Response, and Web Streams was presented.

But why does Node.js need a new HTTP server after more than 15 years? This talk explores the limitations of the current HTTP implementation, the challenges of evolving one of Node.js' oldest subsystems, and the motivations behind a new HTTP stack currently in development. While it's still too early to reveal all the details, we'll look at the problems we're trying to solve, the role of Web Standards in the design, and what this work could mean for the future of server-side JavaScript.

Observability tools in Node.js have changed quite a bit over time. As the language has evolved, the tools have had to keep up. Today, we have more complete and performant solutions than we've ever had before. In the future, we might be able to do even better.

This talk explores the history, the current state of the art, and the ideal future of observability primitives and instrumentation in Node.js.

JavaScript framework authors face a brutal tradeoff when it comes to observability: either ship "blind" code and rely on third parties to brittlely monkey-patch your API, or bloat your bundle with heavy observability dependencies. Both options hurt developer experience and performance.

Tracing channels changed this — a native, zero-dependency pattern that allows frameworks to emit events that are contextualized and execution-correlated end to end. In this session, I'll show how tracing channels enable open observability APIs that progressively enhance with newer Node.js versions and gracefully degrade with zero overhead.

We are leading an initiative to get libraries to adopt tracing channels, so we'll look at the top libraries and frameworks that have adopted it so far and what it means for APMs, users, and observability. The instrumentation tax no longer has to be paid.

Today's Node.js APM tooling is built on monkey-patching. Sentry, OpenTelemetry, dd-trace — they all reach into libraries from the outside, mutating require() cache entries to inject observability. This is fragile, ESM-hostile, and breaks every time a library refactors.

diagnostics_channel flips the model: libraries become active participants in their own observability, emitting structured events that any APM can subscribe to. No monkey-patching. No vendor-specific hooks. One shared bus.

The EU Cyber Resilience Act (CRA) is going to change how organisations build and ship products around the world — no longer will cybersecurity standard conformance be a marketing tool, it will be the baseline. This will impact all the roles in product development differently, and go far beyond your organisation's SPDLC checklists.

We'll go over the more important details of what's in the CRA, and then dive into how application developers might find themselves working toward initial conformity, and integrating cybersecurity requirements into their everyday work.

Quantum computing changes the threat model for much of the cryptography we rely on today, but the transition to post-quantum cryptography is not a single switch that every application needs to flip at once.

This talk explains, with little cryptography background required, the practical risks quantum computers pose to current cryptographic systems, the global state of the migration from traditional to post-quantum algorithms, and how quantum-resistant primitives are being introduced incrementally in Node.js.

We'll look at what Node.js enables today, what is still emerging through standards and platform support, and how developers should think about adoption without over-focusing on the wrong layers. You'll leave with a clear sense of which risks are urgent, which changes are infrastructure-led, and where application developers actually need to pay attention.

A lot is going on in supply-chain this year. Not just the attacks! We're getting improvements out in the ecosystem that have the potential to eliminate some of the most popular ways malware on npm attacks us.

Let me give you a comprehensive overview of how to best use the latest tools and techniques available. And you know I'll be editing the slides on the night before to keep up.

Learn what your publishing setup should look like to avoid getting compromised in non-obvious ways, how to set up the project to avoid shipping malware to your users, and how to protect your local development. We'll also look at the tools we're building in anticipation of where the attackers will go once install scripts are no longer satisfactory for them.

To secure their open source dependencies today, developers face an impossible choice. As AI increases attackers' capabilities, the pressure to fix vulnerable dependencies fast has never been higher, but reckless updates bring broken builds, production incidents, performance regressions, and worst of all malware. Update slowly behind cooldowns and stay exposed to known vulnerabilities; update aggressively and walk straight into poisoned releases. There's no good answer.

Instead of trying to build some contrived "smart updater" agent, we asked a different question: suppose you never want to update your dependencies — what would it actually take to delete every CVE? Can we produce a correct, minimal, behavior-preserving fix for every version of every vulnerable package, for every vulnerability ever published?

The answer turns out to be less a clever trick than an economics problem. I'll give an overview of how we're attacking this problem at Socket, how we're working to get these patches deployed across the broader open source ecosystem, and why we think it's only going to get worse as AI models continue to improve. Along the way I'll tell you how our system evolved, which of our initial ideas did not survive contact with reality, and what we ended up actually shipping.

Release schedules sound boring until you realize how much of the ecosystem depends on them.

Over the years, the Node.js release process has accumulated a lot of operational complexity: maintenance burden, overlapping support timelines, ecosystem coordination, CI scaling, security patching, and the pressure of balancing stability with fast-moving JavaScript tooling. Starting with Node.js 27, the project is moving toward a new release model intended to better match the realities of the modern ecosystem.

We'll explain why these changes are happening, what problems they are trying to solve, and what the practical impact may look like for library maintainers, companies, core contributors, and everyday Node.js users — along with some of the behind-the-scenes challenges of evolving release engineering at the scale of Node.js.

We will tell the story of how node:ffi made its way into Node.js core: from the original implementation work by Bryan English, through the renewed initiative started by Colin Ihrig, to the final design and implementation now landing in Node.js.

We'll walk through the original exploration, the technical challenges, and the lessons learned while trying to expose foreign function interfaces safely and ergonomically to JavaScript developers, then cover the final implementation, the API shape, the design trade-offs, and the performance characteristics measured along the way.

This talk is for anyone interested in native interoperability, Node.js internals, performance, or the long path from an experimental idea to a core module.

Most Node.js apps spend most of their time handling HTTP. Yet the default server path still carries a lot of unnecessary per-request and per-header overhead in pure JavaScript: string concatenation for header blocks, multiple write calls to finish responses, repeated validation steps, and keep-alive work recomputed on every request instead of being reused.

Over the past several months I've been optimizing this path in Node core. First, cutting constant overhead in the public http API by caching validation decisions, adding known-header filters, sharing keep-alive state, and avoiding an extra empty write at the end. Then, adding a native single-shot response builder that serializes the typical HTTP/1.1 header block and optional body directly in C++, while leaving the public API and the wire format unchanged. On a keep-alive hello-world benchmark the native builder alone took throughput from roughly 80k to 118–126k requests per second on the same machine.

This talk walks through the measurement methodology — interleaved A/B testing and Welch's t-tests, rather than cherry-picking one good run — the edge cases that forced fallbacks, what we learned comparing our changes with similar code in Bun, and a practical checklist for anyone optimizing I/O-bound Node.js code: what should stay in JavaScript, what belongs in C++, and how to ship big performance wins without breaking compatibility.

The toolchain generating Node.js API documentation dates back to 2012 and Node.js v0.6.x. Before the io.js fork, before npm had a lockfile, before Node.js even had a foundation. For fourteen years it lived inside Node core, wired into the Makefile, helping power over twenty major versions. It worked. But "works" and "ready for the next ten years" aren't the same thing.

This talk is the story of doc-kit, the standalone, customizable tool built to replace that pipeline. doc-kit parses, lints, and transforms markdown into an AST that generates a dozen output formats from a single CLI command: redesigned web pages, pixel-perfect legacy HTML, man pages, JSON schemas, search indices, and llms.txt for AI. And it'll output whatever comes next.

You'll also hear the human side of maintaining critical open source infrastructure responsibly: the patience required to build consensus across contributors, the discipline of shipping backward compatibility before ambitions, and how to balance the needs of machines, contributors, and the millions of developers who read these docs every day.

Module Federation lets a Node.js process load independently deployed code at runtime. Nobody talks about the second half: once a federated ESM graph is loaded, how do you update it, retire it, and actually get the memory back without restarting the process?

This talk explores versioned graph boundaries as an alternative. Load checkout@v2 next to checkout@v1, route new traffic to v2, drain the old requests, and let v1 become collectible when nothing references it.

From there we'll look at how ShadowRealm's separate module graphs, SES Compartments' capability model, and Node's loader APIs point toward server-side federation that can update, drain, and clean up after itself — including AI Mini Apps that need independent deployment without inheriting the whole process.

I'm building a runtime which is taking as extreme an approach as possible to doing absolutely everything possible from JavaScript and deferring to FFI where necessary rather than integrating much managed code directly. It introduces some different constraints but also enables some interesting capabilities.

A deep dive into one of the biggest multi-tenant systems ever built with Node.js, powering millions of uploads and requests per day at Supabase.

We'll explore the architecture of that system — how tenants are isolated, how uploads and reads are routed, and where the hard edges turned out to be — and how it was scaled over time as the workload grew.

Success on a high-stakes assessment platform doesn't always look like a feature launch. It can look like nothing happening at all.

When I joined WISEflow, our frontend estate had no shared Node tooling: jQuery, AngularJS, and a growing React monolith, each built and deployed its own way, with no real way to know what was breaking beyond user complaints. Getting buy-in meant making one promise to management — modernizing wouldn't slow down feature delivery. It didn't; it sped it up.

I standardized dozens of independently deployed React frontends onto the same Node-based build stack: Vite for builds and dev servers, Biome for linting and formatting, cutting CI time 2–3×, while every component was rewritten functional with modern data-fetching and error tracking scoped narrowly enough to respect student data law. Between the shared tooling, adopting AI-assisted development, and training the team to use both, merged PRs more than doubled — with a smaller team than when we started.

All of it shipped to 150 institutions in 14 countries, 4.1 million exams a year, up to 90,000 people testing at once, without a single participant noticing a thing. This talk is that playbook: the Node tooling decisions that let a small team modernize dozens of production frontends without slowing feature delivery, and how to prove it paid off.

We've all experienced that moment: your build passes, but after a minor tweak your IDE is flooded with errors. Just because it compiles doesn't guarantee that your types are functioning correctly.

In this talk I'll explain why it matters that type definitions are reliable. With TSTyche you can test your types just like you would write unit tests — identifying regressions, ensuring invalid data is rejected, and maintaining compatibility across different TypeScript versions without slowing down your CI pipeline.

It's all about practical ways to make your type system truly beneficial.

Cloudflare's Rust Workers project brings Rust support to Cloudflare Workers through WebAssembly, extending the V8 sandbox beyond JavaScript. Rust Workers uses the same WebAssembly toolchains that have targeted browsers and Node.js for many years.

Despite their maturity, significant challenges remain in supporting native Rust applications — particularly in reconciling their assumed POSIX semantics with JavaScript runtime models, and their differing approaches to asynchronous tasks and I/O.

We'll share experimental contributions to Tokio that provide JavaScript-friendly epoll virtualization, culminating in a demonstration of full-featured Rust applications running on both Cloudflare Workers and Node.js.

Use Pear CLI and a module to deploy peer-to-peer over-the-air updates to terminal, desktop, and mobile applications.

Then use Bare, the zero-core JS runtime, to embed the same P2P-capable local backend in terminal, desktop, and mobile applications — a write-once, run-anywhere RPC application sidecar.