Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 85 posts

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

#51

Post by BearOso »

colinmcd wrote: post #34
jpambrun wrote: post #33

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?

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. I…

I'm seeing lots of bots/agents misusing backticks like this. It's because people are writing agent plans in markdown and the agent thinks it's appropriate everywhere. Maybe you shouldn't be running all your comment replies through Claude.

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

#52

Post by colinmcd »

pier25 wrote: post #48

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.

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.

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

#53

Post by llbbdd »

johnfn wrote: post #23
ivanjermakov wrote: post #14

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).

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 he…

I had a lot of very good times with CoffeeScript but I'll never forgive it for having implicit returns. So many subtle event-bubbling bugs caused by that.

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

#54

Post by NamlchakKhandro »

colinmcd wrote: post #35
johnfn wrote: post #23

Earlier quoted context omitted.

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 he…

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

ye wot mate?

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

#57

Post by fartcoin67 »

BearOso wrote: post #51
colinmcd wrote: post #34

Earlier quoted context omitted.

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. I…

I'm seeing lots of bots/agents misusing backticks like this. It's because people are writing agent plans in markdown and the agent thinks it's appropriate everywhere. Maybe you shouldn't be running all your comment replies through Claude.

Dude people have been doing this since long before LLMs. It's more an artifact of Slack than anything.

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

#58

Post by thayne »

afavour wrote: post #46
hungryhobbit wrote: post #19

Earlier quoted context omitted.

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…

Isn't this a problem contained to npm more than Node itself? I'm imagining pnpm or others being able to adopt a package.json file that allows comments, then, when actually publishing, ensuring the published package.json is regular JSON.

No. Node.js uses package.json as well

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

#60

Post by conartist6 »

matt_kantor wrote: post #42
hungryhobbit wrote: post #19

Earlier quoted context omitted.

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…

> 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.

Yeah stripping out comments at publish time would have been the smartest move. Keep in mind though that a git repo can be used as a package, so there isn't necessarily going to be an explicit publish step
Post reply on HN