Show HN: Nub – A Bun-like all-in-one toolkit for Node.js

162

ccolinmcd about 7 hours ago 40 commentsRead Article on github.com

⚡ Community Insights

Discussion Sentiment

85% Positive

Analyzed from 1236 words in the discussion.

Discussion (40 Comments)Read Original on HackerNews

colinmcd•about 6 hours ago

Colin here, creator of Nub. I’ve had the general shape of this in mind for years. Nub runs your code with stock `node`, augmented with a `--require` preload hook[0] that adds a transpiler (oxc-powered, packaged as a Node-API add-on), registers a module resolution hook[1], and injects polyfills as needed for APIs like `Worker`, `Temporal`, etc. All purely additive, your code ultimately runs using Node’s actual engine & stdlib implementations.

[0] https://nodejs.org/api/cli.html#-require-module

[1] https://nodejs.org/api/module.html#moduleregisterhooksoption...

eyelidlessness•about 4 hours ago

I’m surprised to see this using a `--require` hook (rather than `--import`). Maybe something’s changed significantly since I was looking into building some similar functionality… but it makes me wonder about nuances in nub’s ESM support.

(When I was investigating this it was very early in Node’s `--import` story, but there were several edge cases with the more common ESM-to-CJS approaches that I wanted to address. Most were probably exceedingly niche concerns, but I’d expect top-level await to affect a meaningful subset of users.)

colinmcd•about 3 hours ago

We use this to register our preload purely for performance reasons. In this and many other cases CommonJS is still faster than ESM. Using --require is about 0.5ms overhead vs 4.6ms for --import (on my M1 Macbook Pro).

Relatedly Node.js recently (2025) introduced a synchronous version of its resolver hook registration API (`module.registerHooks()`) specifically to improve performance over the old async `module.register()` API. It was a big unblocker for Nub. For the interested, the async API added 19ms fixed registration overhead + about 130us additional overhead per import.

Which flag Nub uses here doesn't impact userland at all, TLA is supported wherever it's supported by Node.js itself.

eyelidlessness•about 2 hours ago

Thanks! From what you say here and what I see in the docs, it looks like everything is much simpler and more robust than when I was exploring the space. I’m happy to see that, and thrilled it’s mature enough now to support use cases like nub.

awaseem•about 5 hours ago

I saw this on twitter and loved it, such a good move on your part Colin. Hope the project picks up tons of steam!

ivanjermakov•about 5 hours ago

Respect for embracing existing tech instead of rewriting a worse version of it. Wonder where we would be today if all alternative-building effort went to Node instead (with proper leadership).

johnfn•about 4 hours ago

You might remember the io.js fork of Node.js back in 2014. Node was stagnating, a bunch of people forked it into io.js, which eventually got merged back into Node and got it back on track. Or, going further back, CoffeeScript, a "fork" of JS that had its best ideas adopted back into ES5.

A small scrappy team can prove out a good idea because failure is not a catastrophic risk to them. In short, forks are part of a healthy ecosystem.

colinmcd•about 2 hours ago

I almost called it "oi" but I'm not sure anyone would have gotten the joke :P

hootz•about 3 hours ago

It is still happening, a lot of things are still being adopted by Node after being available on other runtimes. They aren't forks, but they still provide pressure towards progress.

psygn89•about 2 hours ago

Beautifully stated reminder :)

hungryhobbit•about 4 hours ago

Fundamentally you can't fix a lot of things with this approach.

Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments").

When an organization digs into bad decisions, the only way to fix them is to start something new. The entire JS ecosystem will never have documentation on its config as long as everyone keeps building on top of Node.

(And there are many other issues like this in the Node ecosystem; the utter absurdity of not being able to document config is just my personal pet peeve.)

matt_kantor•13 minutes ago

> Simple example: [package.json is JSON]

Why can't you fix this while embracing existing tech? I can imagine monkeypatching Node & NPM to add support for JSONC or JSON5 or whatever in the same way that Nub adds various features via monkeypatching. Is there some architectural reason that can't work?

You'd need `npm publish` to compile it down to plain JSON when publishing, but that seems like an okay compromise.

colinmcd•about 1 hour ago

EDIT: Sorry, I understand you're talking about package.json. Would be fun to try to get the Node & package mgmt teams aligned to add support for comments in the package.json. Bun tried and failed to do this (requires ecosystem coordination).

Nub could absolutely support a config file and use it to set NODE_OPTIONS or flags in the node child process. There's no reason to throw out the baby with the bathwater due to DX concerns like this. That's a key part of the concept Nub is trying to prove. (To be clear I'm quite content to conform to Node's no-config-file policy at the moment.)

johnfn•about 4 hours ago

> Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments").

Tangential but this also drives me absolutely nuts. If I have to see `"//": "some comment"` one more time I'm gonna lose it.

gorjusborg•about 5 hours ago

Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)

Zambyte•about 5 hours ago

They'll get bought out by OpenAI and convert the project to Zig

airstrike•about 4 hours ago

huh, is OpenAI embracing Zig specifically? TIL

allthetime•about 3 hours ago

It’s a joke about how Anthropic bought bun and then rewrote bun from zig to rust with a giant one week vibe code. The joke hinges on the fact that this would be the opposite (OpenAI, nub, rust to zig)

lacoolj•about 4 hours ago

It also helps if you're already vibe-coded and don't have customers to begin with

skrebbel•about 4 hours ago

Bun had customers?

ssalbdivad•about 6 hours ago

Just merged a PR migrating our entire monorepo to nub.

0 issues, ridiculously fast.

daavin•about 6 hours ago

You merged a PR migrating a shared monorepo using this within an hour of it being posted?

colinmcd•about 4 hours ago

It entered public beta last week, but just getting on HN now.

jpambrun•about 2 hours ago

Am I expected to be able to run this in production on the backend, or do I still need to transpile and bundle? Do we expect the performance and memory overhead to be negligible. What would be the expectations on terms of added attack surface?

colinmcd•about 2 hours ago

Right now, you should use Nub on the backend if you are relying on its augmentations. If you specifically want to disable Nub's augmentations (so you have a guarantee that your app/script will "just work" with regular Node, there's a couple ways to disable it.

  NODE_COMPAT=0 nub index.ts
  nub --node index.ts

I'll investigate a `nub build` that would do the transpilation upfront and properly chunk/bundle a prod build. It's a good idea. But yes, Nub's overhead (both time and space) is generally negligible relative to Node itself.

Re: added attack surface: the most obvious one is that Nub loads .env files (same as Bun/Next/Vite) so be aware of that. All of Node's permission flags are passed through as well. I won't claim there's no additional attack surface, but it doesn't have much surface area, just a Rust wrapper that spawns `node` ultimately.

skybrian•about 4 hours ago

> TypeScript-friendly resolution: extensionless imports, tsconfig.json#paths

I’m wondering how that works. Deno has very complicated import resolution, so building my own import resolver to be compatible with it is a bit of a pain. (This is for a custom lint-like tool.)

kandros•about 5 hours ago

Love the idea, learning a lot of interesting things about node hooks by reading docs and some code

sgarrity•about 6 hours ago

I didn't even click on the link. I just came to give the author a hat-tip on the project name. Well played.

colinmcd•about 5 hours ago

Thanks :) Highly recommend clicking the link too!

bookernath•about 6 hours ago

Nice, I think this fills a niche. Does it work on cloudflare workers?

colinmcd•about 6 hours ago

Cloudflare Workers is a different runtime and has its own toolchain around it. Nub could theoretically support it when executing files (spawn `wrangler dev` instead of `node` if wrangler.toml is detected or something) but really I'm focused on making the Node.js experience as good as possible.

The other pieces of the toolkit could absolutely be used: package manager, script runner, package runner. Works with anything that implements the Node module resolution algorithm (actually Yarn PnP also works out of the box...).

montroser•about 4 hours ago

Nice. Can we get `nub --compile` up in there like Bun has?

colinmcd•about 4 hours ago

Coming very soon!

allthetime•about 3 hours ago

I will seriously consider migrating once this exists! I couldn’t imagine deploying any other way now. I can never go back from SCPing a single binary to my server and just hitting reset on the service.

esafak•about 2 hours ago

Will you be able to integrate aube updates after vendoring it? https://github.com/nubjs/nub/pull/81

colinmcd•about 1 hour ago

Certainly. We're using subtrees now instead of submodules, lets avoids some tricky worktree/submodule interactions during local dev.

We've already pulled changes since that PR landed.

https://github.com/nubjs/nub/commit/b4abee87

GL26•about 6 hours ago

nice ! does this work on docker containers ?

colinmcd•about 5 hours ago

Yep, full support on macOS, Linux, Windows. No official image yet (I'll start on this now) but you can get started with something like this.

  FROM node:26-slim
  RUN npm i -g @nubjs/nub

Works with any Node version down to 18.19 but recommend 22.15+ for best performance (that's when synchronous registerHooks was introduced[0])

[0] https://nodejs.org/api/module.html#moduleregisterhooksoption...