Schedule

You've been deploying Node.js wrong. For years, the community has treated Node.js as a simple runtime—start a process, put it behind a reverse proxy, scale horizontally. But this approach ignores fundamental architectural problems that become painfully obvious in production: the single-threaded event loop bottleneck, inefficient resource utilization, fragmented tooling, and the operational complexity of managing multiple services.In this talk, I'll make the case for why Node.js needs a proper application server—and why we built Watt to solve these problems. We'll go deep into the architecture: how SO_REUSEPORT enables kernel-level load distribution without IPC overhead, how multiple workers within a single deployment unit can achieve near-linear scaling, and how a unified runtime can orchestrate frontend frameworks like Next.js alongside backend microservices.You'll see real benchmark data: 93% faster median latency compared to PM2 clusters, 99.8% reliability under sustained load, and dramatic reductions in infrastructure costs.

I will provide an in-depth analysis of the initiatives led by the Node.js Security Team, exploring their significance and the benefits they bring to end-users. Since 2022, we've accomplished a lot of tasks and the goal of this talk is to showcase the concluded initiatives, highlighting the advancements made in fortifying the security of Node.js applications. Furthermore, I'll unveil what you can expect from upcoming releases, offering a glimpse into the future of Node.js security. From vulnerability management to secure coding practices and beyond, this talk will equip you with valuable insights into the measures taken to enhance protection and ensure a more secure Node.js environment.

We all know the ritual: add a dependency, trust it implicitly, ship it to production. For years, that worked well enough. But now the attacks have started getting smarter.Supply chain attacks targeting the npm ecosystem aren't theoretical anymore. Malicious packages that steal credentials, hijack environment variables or silently exfiltrate data over HTTP are showing up in minor version bumps.

At Cloudflare we have a lot of products. Our REST OpenAPI spec is over 2.3 million tokens. When teams wanted to let AI agents access their services, they did what everyone does: cherry-picked important endpoints for their product, wrote some tool definitions and shipped a an MCP Server that covered a small fraction of their API.I think we got it all wrong.The context limit is not an MCP problem. It's an Agent problem.

Node.js introduces --experimental-config-file, a new experimental flag that enables loading a node.config.json file at startup. While it adds yet another config file, this powerful addition finally allows developers to customize Node.js execution in ways that were previously impossible. This talk explores the capabilities unlocked by this feature, including fine-tuned runtime behavior, improved portability, and potential future extensions.

Cap'n Web is a new open source library that lets you expose JavaScript and TypeScript APIs across the Web, including over HTTP or WebSocket. Unlike almost all other RPC systems before it, Cap'n Web supports passing functions and objects over RPC "by reference". This simple-sounding feature has deep implications that completely change how APIs are designed. In this talk I will present a series of examples showing how to use Cap'n Web's first-class functions and objects to implement a variety of common API design patterns, such as authorization, pub-sub, and streaming.

Node.js applications are increasingly defined by their dependency graph, yet most tooling still treats it as an opaque side effect. node_modules hides structure, workspaces are layered on, and understanding how dependencies relate (or even why they exist) remains surprisingly difficult.This talk introduces the vlt client and shows what becomes possible when the dependency graph is treated as a first-class JavaScript artifact. By exposing graph construction, resolution, traversal, and querying as reusable JavaScript primitives, vlt enables both powerful CLI workflows and entirely new classes of programmatic tooling. Building the client in JavaScript ensures that advances in package management feed directly back into the ecosystem, strengthening the shared library corpus and raising the ceiling for Node.js tooling.

While the Web streams API provides a uniform approach to streaming across all runtimes, it comes with steep performance costs and significant implementation complexity. We can, and should, do better.

Run your project without drowning in configuration. For common scenarios, you can do, config-free via simple extensions using node's Customization API (you don't need to know what that is). It can be about as simple as telling node you want to use css modules and tsx: module.register('@nodejs-loaders/css-module').

Modern JavaScript runtimes don’t only manage JavaScript objects — they also need to safely and efficiently garbage collect complex native objects written in C++ and Rust. This talk explores how V8’s cppgc (Oilpan) is used in Node.js, Deno, and Cloudflare Workers, comparing shim-based approaches with direct cppgc integration and explaining the performance and lifecycle trade-offs behind each design.

I've been contributing a Conformance Test Suite to the Node.js project: For Node-API implementors to run across different JavaScript engines and runtimes, such as Bun, Deno and React Native.I want to share motivation for the project, architectural decisions, the progress we've made so far and key techniques used to ensure the implementation stays runtime agnostic.

Benchmarks are everywhere, but production rarely looks like a benchmark.This talk compares Node.js, Deno, and Bun from a pragmatic, production-first perspective: debugging, observability, deployment, cold starts, and the kind of edge cases that only appear when real users and real systems are involved.

Building apps with TypeScript is the norm these days, but there's one major pain point, speed. At first, everything runs smoothly, but as your project grows, build times drag, your editor lags, and even basic code completion slows to a crawl. The good news? A solution has been hiding in TypeScript’s documentation for years, overlooked but incredibly effective.

Every Node.js developer adding AI to their apps faces the same choice: pay for external APIs or wrestle with some local inference like Ollama (that also requires API calls). But there's a third option nobody's talking about: running ML inference *inside* your Node.js process with Transformers.js. In this talk, I'll show you how to generate embeddings, classify text, and run LLMs with nothing more than `npm install`. No API keys, no network latency, no separate processes.

MIT's recent ""Recursive Language Models"" paper demonstrated that LLMs can process inputs 100x beyond their context windows — not by expanding the window, but by treating prompts as external environments the model explores programmatically. The results are striking: GPT-5-mini outperformed GPT-5 on long-context tasks while using comparable compute. This talk demonstrates how to build the same architecture in TypeScript using LangGraph and Node.js.We'll implement an RLM system in which a root agent orchestrates recursive sub-agents, each operating on a focused context slice without suffering ""context rot."" We'll see how to leverage LangGraph's cyclic graph execution to spawn child agents, aggregate their findings into a shared state, and let the orchestrator synthesize results — all while keeping individual context windows small and fresh.By the end, you'll have a working pattern for processing massive documents, codebases, or datasets that would choke a single LLM call, using tools you can deploy today.Key takeaways:- Why bigger context windows don't solve context rot- Architecting recursive agent graphs in LangGraph- Managing state and tool execution across agent hierarchies- Cost and latency tradeoffs in production

You’ve been there: Node.js tests pass both locally and in CI. You deploy with confidence. Then staging reveals the truth—bugs that only appear with real Postgres 16 collations, actual Redis connection limits, or Kafka partition behavior your in-memory mocks never captured.The solution are Testcontainers.Testcontainers is a testing library that provides easy and lightweight APIs for bootstrapping integration tests with real services wrapped in Docker containers. Using Testcontainers, you can write tests talking to the same type of services you use in production without mocks or in-memory services.

What's it like to create a test runner from scratch? More than that: how do you test a test runner?In this talk, I break down Poku, a test runner that makes testing easy for Node.js, Bun, Deno, and you.You will learn about the power of subprocesses, isolation, and the advantages of working with concurrency. All of this using only native language features.You will also understand how it is possible, in less than 200kB, to create a complete test runner and run the same test suite through all JavaScript runtimes for backend.