Nub Wraps Node.js in a Rust Shell to Fix Toolchain Lag Without Replacing the Engine

In recent years, the narrative around JavaScript runtimes has been very heated.

Every few months, an article tells you how fast Bun is, or what killer feature Deno has launched. Their touted all-in-one toolchain is indeed tempting: native TypeScript execution, built-in environment variable loading, out-of-the-box testing and building. There's even an illusion in the community that not using a new runtime means falling behind.

But in real commercial projects, reality is often harsh. Forcibly migrating a three-year-old project, entangled with various CI/CD scripts and extremely complex intranet dependencies, to a completely different underlying engine often means incalculable production risk. No one wants to take the blame for a P0 outage just to save a few seconds during development 😖.

So the real question has never been: should we kill Node.js? The more realistic question is: can we keep using rock-solid Node.js, but bring its modern development experience up to par?

This is exactly the question that Colin McDonnell, the author of the well-known type library Zod, recently open-sourced 👉 Nub(https://github.com/nubjs/nub ) to answer.

Even Evan You came over to advertise it 🤣🤣🤣

---

What exactly is Nub? What problem does it solve?

Native Node.js suffers from a serious bare infrastructure problem. It's like a bare shell of a house — the engine itself is very solid, but there's no decoration at all. To piece together a modern development experience, we repeatedly paste the same set of configurations into every project.

Want to run TypeScript? Install tsx or ts-node. Want to load environment variables? Bring in dotenv. Want hot reloading? Install nodemon globally. Want to manage package versions? You'll need corepack.

The older the project, the more these small tools become layers that slowly drag down startup speed. Every time you hit Enter, the system goes through a long chain in the background to resolve these wrappers.

Nub's positioning is very clear: it is a high-performance enhancement shell written in Rust, dedicated to being a ++ version of Node.js.

We can visually compare the past and present development experience:

Development Scenario	Traditional Toolchain	Using Nub	Speed Improvement
Execute TypeScript	tsx or ts-node	nub index.ts	Startup ~2.9x faster
Load Environment Variables	dotenv with startup script	Native auto-loading of .env	Zero-config, direct connection
Hot Reload Watching	nodemon (regex-based)	nub watch (based on real dependency tree)	Precise reload, no false triggers
Execute Project Scripts	npm run dev	nub run dev	Dispatch time ~24x shorter
Execute Ad-hoc Commands	npx eslint	nubx eslint	Cold start ~19x faster

Deep Dive into the Underlying Mechanics

Many people, seeing the 👆 dozens-of-times speed improvements, have a first reaction: is this another modified version of the underlying engine?

It is not. This is where Nub is most easily misunderstood. It is absolutely not a fork of Node.js, nor will it replace your system's underlying JavaScript engine like Bun does (V8 remains the absolute core).

Its core working mechanism is high-speed scheduling and hook interception.

Traditional tools (like tsx) are slow not because of compiling code, but because of the cold start of the tool's own Node.js wrapper process. When you type nub app.ts, the outer Rust binary completes version checks, parses environment variables, and reads tsconfig.json at extreme speed in just over ten milliseconds. Then, it mounts the compiler directly via Node.js's native low-level extension mechanism (module.registerHooks).

Even more impressive, Nub has a built-in oxc ultra-fast compiler written in Rust. This means the transpilation of your TypeScript code (even legacy decorator syntax) is handled by extremely fast Rust, but the final execution of core business logic still runs on your server's original Node.js process.

// Business code requires no modification at all
import config from "./config.yaml"; // Ultra-fast parsing and importing of yaml/toml data formats
import { User } from "./types"; // Seamless TypeScript execution, no loss of type inference

console.log('Configuration loaded successfully:', config);

---

The Deep Waters Often Overlooked

As a front-end engineering veteran who has struggled in production environments, judging a tool is never just about how fast it runs a Hello World 🤷‍♂️.

What truly impressed me about Nub is its fallback design in the deep waters of engineering.

Child Process Escape?

This is the easiest pitfall when building complex CLI tools. When you run an entry file with tsx, if the business logic executes child_process.spawn('node', ['worker.ts']), the child process is a brand new, clean Node process. It usually loses the compilation capability provided by the outer tsx and directly throws a syntax error.

To cover this scenario, Nub cleverly injects a PATH shim into the environment variables during execution. Even if your business code re-invokes node or even npm at a very deep level, it will be intercepted by the underlying interceptor and automatically routed back to Nub's execution context. This ensures capability consistency across the entire process tree, preventing gaps in the development experience.

import { spawn } from "child_process";

// Even if you call native node here, it will be intercepted by Nub's PATH shim
// The child process still enjoys TypeScript compilation and .env auto-loading capabilities
const child = spawn("node", ["worker.ts"], { stdio: "inherit" });

Blocking Third-Party Startup Scripts by Default

Every time you run pnpm install, the postinstall build scripts in third-party dependency packages are like black boxes, impossible to guard against.

Nub even has a built-in package management function (nub install). It uses the ultra-fast aube engine under the hood, which not only installs dependencies 2.5 times faster than pnpm, but more importantly, it adopts a comprehensive blocking strong security strategy by default. It prohibits any self-starting build scripts from third-party dependencies by default, completely returning execution control to the developer for one-by-one review.

---

What Can't It Do?

The tech world fears blind idolization the most. We must soberly recognize the boundaries of Nub's capabilities 🤔.

Nub will absolutely not suddenly make your business APIs 10 times faster. If your backend API is stuck for 2 seconds due to a slow database query, or a loop runs 5 million times, it will still be stuck for just as long after switching to Nub.

What it optimizes is the scheduling overhead of the toolchain (the cold start path), such as the time difference from the moment you hit Enter to when the script actually starts running, or the response speed when you dispatch tasks with nubx eslint. It solves the developer's perceived experience, not the runtime lag of business logic.

---

So, Who Should Try Nub Immediately?

Technology selection is never about chasing trends; we need to make decisions based on real business situations.

Node.js's narrative might not be what it once was, but it's far from retirement. As long as tools like this keep extending its life, this ecosystem can still fight for another decade.

What do you all think? 😁