Can Nub Steal Bun’s Spotlight? Ex‑Bun Engineer Launches Nub, Vite Creator Reacts

Bun excels at packing a suite of Node.js‑centric tools into a faster runtime. A former Bun engineer, Colin McDonnell, asked a different question: why not bring Bun’s developer experience directly onto Node.js? The result is Nub, a project that quickly gained attention when Vite creator Evan You retweeted it.

Why Nub Chooses Native Node.js

Typical Node.js projects juggle many separate utilities: node for execution, npm run or pnpm run for scripts, npx or pnpm exec for CLIs, tsx / ts-node for TypeScript, dotenv for environment variables, nodemon for file watching, and version managers such as nvm, fnm or mise. Each tool works, but the combination feels like an ever‑growing shopping list.

Bun and Deno answer this by rewriting the runtime and bundling the capabilities. Nub takes a more conservative route: it keeps the native Node.js runtime and rebuilds the surrounding toolchain.

Typical Nub commands illustrate the approach:

nub index.ts
nub run dev
nub watch src/server.ts
nubx prisma generate
nub install
nub node install 26

These map respectively to running TypeScript, executing project scripts, watching files, running local CLIs, installing dependencies, and managing Node versions.

TypeScript Support Beyond Simple Execution

Node.js can run some TypeScript directly but relies on type erasure, leaving features like enum, namespace, and parameter properties unsupported. Nub transpiles TypeScript, TSX, and decorators in memory before handing the code to the chosen Node.js process. It also adds several developer‑friendly details:

Full support for paths, baseUrl, and inheritance chains defined in tsconfig.json.

Automatic loading of .env, .env.local, and environment‑specific configurations.

Direct import of YAML and TOML files.

Support for JSX, TSX, and legacy experimental decorators.

Generation of inline source maps so errors point to the original TypeScript source.

Fazt summed up Nub as “the vibe of Bun without leaving Node,” highlighting faster TypeScript, environment variable handling, package management, and command startup. The claim does not imply Nub matches Bun’s speed in every scenario.

Nub deliberately avoids new global APIs such as Nub.* and does not introduce its own package.json fields. While this reduces tool‑binding, projects that rely on YAML/TOML imports, automatic .env loading, or custom tsconfig.json paths still need to adjust configurations when switching back to plain Node.js.

Performance Claims

The official benchmark highlights two headline numbers: nub run is 24× faster than pnpm run, and nubx is 19× faster than npx. These figures measure the overhead of script and CLI startup, not the speed of user code. The test runs near‑empty scripts and fast‑terminating native CLIs to isolate the packaging layer’s cost.

In a “warm install” test on macOS, rebuilding a create‑t3‑app project with 222 dependencies took 1122 ms with Nub, 1444 ms with Bun, 2847 ms with pnpm, and 4163 ms with npm. Another test shows Bun still outperforms Nub by roughly 4× for simple TypeScript execution because Bun avoids the Node.js startup cost entirely.

Thus Nub’s speed advantage resides mainly in the tool‑wrapping and installation phases, not in raw JavaScript/TypeScript execution.

Package Management and Security

Nub’s most aggressive feature is its built‑in package manager. It can read and rewrite npm, pnpm, and Bun lockfiles (Yarn lockfiles are read‑only). For pnpm projects it claims support for workspaces, hooks, and package.json ‑based pnpm configuration.

The default security policy is stricter than typical installers:

Dependency lifecycle scripts are disabled by default and run only after explicit approval.

Indirect dependencies from git+, file:, or raw tarball URLs are blocked.

Newly published versions are held back for 24 hours before entering the dependency tree.

Packages with missing provenance or untrusted publishers are rejected rather than silently downgraded.

These measures reduce supply‑chain attack risk but may introduce compatibility friction, especially for packages that rely on postinstall scripts.

Why Integrated Toolchains Are Gaining Traction

Evan You linked Nub to Vite Plus, noting that both projects pursue speed and a more unified developer experience. The underlying belief is that JavaScript tooling has become fragmented, and the ecosystem is moving toward tighter integration.

At present Nub does not cover the full spectrum of linting, formatting, testing, and building, so it functions more as an ambitious entry point for a Node.js toolchain rather than a complete “all‑in‑one” suite like Bun.

What Nub Actually Replaces

Nub does not replace Node.js; it depends on it. It also cannot fully replace Bun because Bun bundles its own runtime, bundler, test runner, and broader integration.

By consolidating tsx + dotenv + nodemon + npm/pnpm + npx + nvm into a single entry point while keeping the native runtime, Nub offers a low‑migration‑cost path for developers who want a more streamlined experience without abandoning existing Node.js projects.

The main advantage is reduced migration friction, but the biggest risk is the breadth of responsibilities Nub assumes—runtime execution, package management, version control, and script scheduling—all of which involve many edge cases. Since Nub is newly released, its stability in production workloads remains unproven.

Nevertheless, the direction is worth watching: if Nub later adds linting, formatting, testing, and building, it could challenge Bun not just for Node.js users but for a “Bun‑like” experience built on top of Node.js.