Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I didn't even click on the link. I just came to give the author a hat-tip on the project name. Well played.
    by sgarrity
  • It shows
    by gnabgib
  • Thanks :) Highly recommend clicking the link too!
    by colinmcd
  • The readme says Websockets support is native from Node 22, except Node does not have a native Websockets library. Their link for Websockets standard goes to MDN, which is fine except that only describes the WHATWG user interface and nothing about the protocol or how Websockets works.

    It feels like this is missing something or using a nonnative library as a supplemental addition.

    by austin-cheney
  • Node supports a built-in WebSocket client since 22, but not a server.
    by soulofmischief
  • Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
    by gorjusborg
  • Bun had customers?
    by skrebbel
  • There's a difference between running your app on a vibe coded runtime or just local DX tools though.
    by pier25
  • Yea, not sure what “written in rust” adds to this. I would have thought that you could get the same functionality with a few shell scripts and a package.json.
    by coneonthefloor
  • “If you are already vibe-coded in Rust”, probably is better, Nub has a strong smell all the way (which is ok, just funny to compare with Bun).

    P.S. The entire Bun’s anti-AI hysteria makes me very sad, sometimes it feels like a directed campaign

    by leobuskin
  • It also helps if you're already vibe-coded and don't have customers to begin with
    by lacoolj
  • This project is already highly vibe-coded. Claude is the second contributor of the repo.
    by maxloh
  • They'll get bought out by OpenAI and convert the project to Zig
    by Zambyte
  • I actually really like this! Great choices all around.
    by haburka
  • 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).
    by ivanjermakov
  • 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.)

    by hungryhobbit
  • 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.

    by johnfn
  • I saw this on twitter and loved it, such a good move on your part Colin. Hope the project picks up tons of steam!
    by awaseem
  • love this, and the name "nub" is conceptually perfect

    (1) adopts existing tech and improves, rather than a greenfield project with worse compat

    (2) the way it uses existing node mechanisms to implement itself (+oxc) is very smart

    (3) i like that the node.js-forever crowd has a way to use the newest stuff

    by sgammon
  • This is _very_ interesting, thanks for building and sharing it, Colin!

    I've got a couple of decent-sized products running on Deno (and I've been a fan since it came out, not so much since 1.0 and 2.0, but still feel it's better than Node), but Node has been catching up and Deno has slowed down, so this might be the "compatibility middleware" that'll get me to move things back to Node.

    Will keep a close eye on it.

    by BrunoBernardino
  • Hasn't Node been able to run TypeScript for a couple of versions? Why's the transpiler needed?
    by vmsp
  • It says "injects polyfills as needed for APIs like `Worker`, `Temporal`, etc"
    by conartist6
  • The Node.js team removed `--experimental-transform-types` from Node.js v26. This makes native, full TypeScript support impossible.

    https://github.com/nodejs/typescript/issues/51#issuecomment-...

    by chirsz
  • Node's built-in Typescript support is just for type stripping. That works for a massive amount of TypeScript syntax, but not all of it. It also doesn't bother actually checking the types, just removing them so it runs. You also lose things like tsconfig.

    This looks to support both the built-in stripping as well as actual TypeScript.

    by zamadatix
  • Just merged a PR migrating our entire monorepo to nub.

    0 issues, ridiculously fast.

    by ssalbdivad
  • You merged a PR migrating a shared monorepo using this within an hour of it being posted?
    by daavin
  • 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.)

    by eyelidlessness
  • 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.

    by colinmcd
  • Very cool idea which makes a lot of sense. Bun provides more (eg db drivers) but the DX is certainly a big part of its appeal.

    For reference, the main author of Nub is Colin McDonnell who created Zod and even worked at Bun at some point.

    by pier25
  • Indeed, Nub intentionally introduces no Nub-specific APIs: no Nub global, no nub: prefixed built-in modules, no Nub-named config file / lockfile, no "nub" field in package.json, not even any NUB_ environment variables. Most of the stuff Bun added is better as a proper dependency imo.
    by colinmcd