Node.js 24 landed on May 6th. Two days in, I’ve already migrated one personal project and started testing at work. The release is dense — V8 13.6, npm 11, Undici 7, a simplified permission model — but the part that interests me most isn’t any single feature. It’s the pattern these features reveal.

Node is maturing. Not in the “it’s boring now” sense. In the “it takes infrastructure seriously” sense. And that’s exactly what it needs to do to stay relevant.

V8 13.6: The Engine Upgrade That Actually Matters #

Every major Node release ships a V8 upgrade and every release blog post lists the new JavaScript features. Most of them are incremental. This one has a few things worth paying attention to.

Float16Array. Half-precision floating point as a native typed array. If you’re doing any ML inference work in Node (and an increasing number of teams are, whether through ONNX runtime or custom WASM modules), this cuts memory usage in half for model weights that don’t need full precision. It’s also relevant for WebGL interop and any scenario where you’re shuttling numeric data between Node and a GPU-accelerated backend.

Is this going to change most people’s daily workflow? No. But it signals that the V8 team is paying attention to the ML/scientific computing use case, which broadens Node’s reach into territory that Python has owned.

RegExp.escape(). I’ve been waiting for this one since approximately forever. If you’ve ever built a search feature that accepts user input and constructs regex from it, you’ve written your own escape function. Or you copied one from Stack Overflow. Or you used a library that wraps a function someone copied from Stack Overflow.

RegExp.escape() is now a built-in static method. Pass it a string, get back a regex-safe string. It handles all the special characters. It’s in the spec. You never have to think about this again.

Small feature. Eliminates an entire class of bugs. My favorite kind of improvement.

using and await using for resource management. This is the explicit resource management proposal (TC39 stage 3, now shipping in V8 13.6). It lets you declare disposable resources that automatically clean up when they go out of scope:

{
  using file = openFile('data.txt');
  // file is automatically closed when this block exits
}

If you’ve worked with database connections, file handles, or any resource that needs deterministic cleanup, you’ve written try/finally blocks. Lots of them. using replaces that pattern with something cleaner and less error-prone. The await using variant handles async disposal, which covers the database connection pool case that’s probably the most common resource management pain point in Node.

This is a language-level feature, not a Node-specific one, but Node 24 is likely where most developers will encounter it first in production.

The Permission Model Grows Up #

Node’s permission model has been experimental since v20. In Node 24, --experimental-permission becomes just --permission. That flag rename is more significant than it looks.

The permission model lets you restrict what a Node process can access: file system reads, file system writes, child process spawning, and worker thread creation. You run your process with --permission --allow-fs-read=/app/data --allow-fs-write=/app/logs and anything outside those paths gets denied.

For server workloads this is useful but not transformational; you probably already have OS-level sandboxing. Where it gets interesting is for running untrusted code — plugins, user-submitted scripts, third-party integrations. The permission model gives you process-level sandboxing without spinning up a container.

Dropping the experimental prefix signals that the Node team considers the API stable enough for production use. It’s not a full security sandbox (the docs are clear about that), but it’s a meaningful step toward making Node a platform you can run untrusted workloads on without reaching for heavier isolation mechanisms.

npm 11 and Undici 7 #

npm 11 ships as the default package manager. The big change is stricter peer dependency handling, which will break some install scripts in legacy projects. If you’ve been ignoring peer dependency warnings (and who among us hasn’t), this release will make them harder to ignore.

Undici 7, the HTTP client that’s been replacing the legacy http module, brings performance improvements and better spec compliance. The gap between Undici and the legacy HTTP module keeps widening; at this point, if you’re still using http.request() directly, you’re leaving performance on the table and carrying technical debt.

Neither of these is individually exciting. Together, they’re infrastructure maturation: the package manager gets stricter (correctness over convenience), the HTTP client gets faster (performance by default rather than opt-in).

URLPattern Goes Global #

URLPattern, previously available only through an explicit import, is now a global constructor. This is the web platform API for declarative URL matching — think Express route patterns but standardized across Node, Deno, browsers, and Cloudflare Workers.

const pattern = new URLPattern({ pathname: '/users/:id/posts/:postId' });
const match = pattern.exec('https://api.example.com/users/42/posts/7');
// match.pathname.groups → { id: '42', postId: '7' }

If you’re building any kind of routing layer, this gives you a standardized, well-tested pattern matching engine without pulling in a library. The cross-platform consistency is the real win; code that works in your Node server also works in your service worker and your edge function.

WebAssembly Memory64 #

This one’s niche but consequential. WebAssembly has been limited to 4GB of addressable memory (32-bit pointers). Memory64 support in Node 24 lifts that restriction, enabling WASM modules to address more than 4GB.

Why does this matter? Because WASM is increasingly used for running compute-intensive workloads in Node — image processing, video transcoding, ML inference, cryptographic operations. The 4GB limit was a ceiling that forced developers to either shard their data or drop out of WASM into native modules. Memory64 removes that ceiling.

For most web application developers, this won’t matter tomorrow. For the growing community building high-performance computing bridges through WASM, it removes a real constraint.

The Built-in Test Runner Matures #

Node’s built-in test runner (introduced experimentally in v18, stabilized in v20) gets automatic subtest lifecycle management in v24. Subtests now handle setup and teardown more predictably, and the runner manages the lifecycle of nested test contexts.

I’ve been using the built-in test runner for smaller projects since v20, but the lifecycle management gaps kept me on Vitest for anything complex. This release closes some of those gaps. I’m not ready to abandon Vitest for large projects yet, but the trajectory is clear: Node wants a capable test runner in the box, and it’s getting closer with each release.

The Infrastructure Narrative #

Node.js 24 will enter LTS as “Krypton” in October. Between now and then, the current channel will get patches and minor additions, but the shape of the release is set.

Looking at the feature set as a whole, the story isn’t about any single addition. It’s about Node’s deliberate evolution from “JavaScript on the server” to “infrastructure platform.” Permission model for security. Memory64 for high-performance computing. Resource management for operational correctness. Stricter package management for supply chain reliability.

I’ve been using Node since the v0.10 days. The early years were about proving that JavaScript could work on the server. The middle years were about ecosystem growth (npm became the largest package registry on the planet). This era feels different — it’s about hardening, securing, and maturing the platform for workloads that demand reliability.

That’s less exciting than the early days. It’s also exactly what Node needs to remain the foundation that millions of production services run on. Not every release needs to be revolutionary. Sometimes the best thing a platform can do is get more boring in the right ways.

Krypton. Named after a noble gas that’s stable, inert, and everywhere. Fitting.