Colin Hack knows JavaScript tooling from the inside. His time at Bun, plus authorship of Zod—the validation library that seems to have colonized half of GitHub—gave him a particular vantage point on what developers want. Turns out, they want speed. They want better tooling. But many don't want to abandon Node.js to get it.
So Hack built something in between.
Released in mid-June 2026, Nub is an open-source toolkit that promises many of Bun's performance wins without the commitment ceremony of swapping runtimes. The pitch is deceptively simple: run your package.json scripts 24 times faster than pnpm, execute binaries 19 times faster than npx, all while running on stock Node.js. No fork. No custom runtime. No lock-in, at least in theory.
The project accumulated around 1,800 to 1,900 GitHub stars in its first ten days—a respectable showing that suggests developers are, at minimum, intrigued.
Augmentation Over Replacement
Think of Nub as a toolkit rather than a runtime. It's a single Rust CLI bundling a file runner for TypeScript and JSX, a script runner, a package manager, and a Node version manager. The crucial architectural choice: it orchestrates the user's installed Node binary rather than replacing it outright. Hack calls this augmentation, not substitution, and that distinction isn't just semantic.
Where Bun ships its own JavaScript runtime built on JavaScriptCore, Nub takes a different route. It uses Node's native module hooks and preload mechanisms to inject Rust-compiled transpilation. The oxc parser handles TypeScript, JSX, decorators, and extensionless imports on the fly. According to Nub's own benchmarks, the overhead is minimal—44 milliseconds to start a TypeScript file with Nub versus 44 milliseconds with plain node. Compare that to 128 milliseconds with tsx.
There's another small convenience: Nub auto-enables Node's experimental features based on version detection. APIs like Worker, Temporal, URLPattern, and the built-in SQLite support get unflagged automatically when they're available. It's a minor quality-of-life improvement, but one that addresses Node's tendency to gate newer functionality behind flags that developers routinely forget to set.
The Numbers Behind the Hype
That 24× figure for script execution? It comes from cold and warm dispatch benchmarks against pnpm run, with methodology and raw numbers published on GitHub. Similarly, the 19× claim for nubx—Nub's answer to npx—is anchored in measured runs of esbuild --version on a warm cache.
On package installation, Nub posted a 1.122-second time to install create-t3-app's 222 dependencies on macOS with a frozen, warm cache. Faster than Bun (1.444 seconds), pnpm (2.847 seconds), and npm (4.163 seconds). The package manager underneath is aube, a Rust-based engine built by Jeff Dickey, who also maintains mise. Dickey describes aube as targeting "speed + strong security defaults," and Nub inherits both.
Whether those benchmarks hold up in messier, real-world environments remains to be seen. Benchmarks have a way of looking pristine until they meet production codebases.
Security Posture: Paranoid by Design
Here's where things get interesting. Nub ships with lifecycle scripts denied by default—a stance that might frustrate some teams but reflects hard lessons from the npm ecosystem's recurring malicious-package incidents.
A curated allowlist covers known native packages like esbuild and sharp, but only after checking provenance and applying a 24-hour cooling window on newly published releases. The tool also blocks non-registry transitive dependencies—git, file, and tarball URLs—to prevent supply-chain detours.
Hack's launch post explicitly frames these defaults as a response to the "newly published patch hijacks installs" attack pattern. For teams inheriting legacy codebases with dubious install scripts, the posture might prove too restrictive. For greenfield projects, though, it's a reasonable starting baseline—perhaps even overdue.
Playing Nice with Existing Toolchains
Nub reads and writes existing lockfiles in place, which matters more than it might sound. Package-lock.json v2 and v3, pnpm-lock.yaml v9, and bun.lock are all supported for read-write round-trips. Yarn.lock gets read-only treatment, presumably because yarn's lockfile format is... let's say "finicky."
The tool honors npm's config cascade, pnpm's workspace selectors, and a subset of Bun's trusted-dependencies configuration. That compatibility design is deliberate. A team using pnpm can swap in nub install without rewriting their lockfile or reconfiguring CI. Nub even ships Corepack-style shims that route bare pnpm, npm, or yarn commands through Nub's faster dispatch layer while preserving the underlying package manager's semantics.
For CI, there's a GitHub Action—nubjs/setup-nub—that installs Nub, provisions the pinned Node version, and caches the Nub store. The action's documentation indicates active maintenance in the initial weeks following launch.
Early Days, Rough Edges
Third-party write-ups began appearing within days. A Spanish-language comparison post described Nub as "promising but buggy right now," advising against replacing established workflows just yet. That verdict might be premature—Nub hit v0.2.0 less than two weeks after its initial release—but it reflects the natural skepticism around alpha-stage tooling in production environments.
The project is MIT-licensed and has no announced funding or formal company structure. It's Hack and a small group of contributors iterating in public, which is either reassuring or concerning depending on your tolerance for early-stage open source. The repo includes a cross-runtime compatibility harness that benchmarks Nub against Node, Bun, and Deno using a pinned corpus, with deltas attributed to Nub's auto-enabled experimental flags and native addon handling.
A Middle Path, Or Just Another Detour?
For now, Nub represents a bet that JavaScript developers want a faster, more opinionated Node.js experience without the friction of adopting an entirely new runtime. Whether that bet pays off depends on two things: how quickly Hack can close the rough edges, and whether the "augment, not replace" philosophy resonates beyond early adopters.
The initial traction suggests at least some appetite for a middle path between Bun's all-in proposition and Node's conservative defaults. Then again, JavaScript tooling has never lacked for ambitious projects promising to solve everything. The question isn't whether Nub is fast—the benchmarks suggest it is. The question is whether speed alone is enough to earn a permanent slot in developers' workflows, or whether this is just another pit stop on the endless march toward the next shiny thing.
Time, and GitHub stars, will tell.
