11 ms·

What's wrong with just using Node? It's stable, has a good (and growing) standard library and has enough backing to be self sustaining. edit: There's also nub

by domh 29d ago

What's wrong with just using Node? It's stable, has a good (and growing) standard library and has enough backing to be self sustaining. edit: There's also nub which is built on top of Node.js and removes some rough/legacy edges: https://github.com/nubjs/nub https://github.com/nubjs/nub

hresvelgr 29d ago
It consolidates a lot of really annoying nits and quality of life aspects like bundling, module resolution, testing, env handling, etc. Node is just the runtime and still would require libs like esbuild, jest/vitest, dotenv, and so on. It's genuinely nice to have those out of the box, and generally in Bun the performance is quite significantly better in places that matter.
- domh 29d ago
  Let me address each one in turn: - esbuild - this is normally for TS compilation, which Node can run natively now by stripping types: https://nodejs.org/docs/latest/api/typescript.html#type-stripping https://nodejs.org/docs/latest/api/typescript.html#type-stri... - jest/vitest: Node has a test runner: https://nodejs.org/docs/latest/api/test.html https://nodejs.org/docs/latest/api/test.html - dotenv: Node can read .env files: https://nodejs.org/docs/latest/api/cli.html#--env-filefile https://nodejs.org/docs/latest/api/cli.html#--env-filefile Performance, maybe you're right - but if you're doing any IO, I doubt the runtime is really the bottleneck.
franciscop 29d ago
Node.js is virtually the only platform not supporting the Fetchable convention: https://github.com/nodejs/node/issues/63096 https://github.com/nodejs/node/issues/63096 https://fetchable.org/ https://fetchable.org/
- domh 29d ago
  That's a fair criticism... they move slower but mostly because they were the first. They would have to build a new Server and Request/Response primitives from scratch, or deprecate what they already have, or somehow shoehorn the existing types into the new ones. They do seem to have just merged in support for Web Workers though, which I've been following for a while: https://github.com/nodejs/node/issues/43583 https://github.com/nodejs/node/issues/43583 So I don't think they're opposed to standardising, but it's trickier when you have some past cruft built up. Lets not forget that the fetch() standard was built for browsers, and is a bit of a stretch to make it work on servers at all. You have to diverge from the fetch spec to even make it make sense in a server environment (with things like Cookies handling off the top of my head).
  - domh 29d ago
    Same thing can be said about Streams in Node.js as well. They had a working streams implementation before the Web Streams API was in browsers (iirc). So implementing the standard now means removing what's already there, or breaking a lot of existing code. Which leads to confusing things like the fact that there are two streams APIs in Node now: Streams: https://nodejs.org/docs/latest/api/stream.html https://nodejs.org/docs/latest/api/stream.html Web Streams: https://nodejs.org/docs/latest/api/webstreams.html https://nodejs.org/docs/latest/api/webstreams.html And they have to support going back and forth between the two: https://nodejs.org/docs/latest/api/webstreams.html#nodejs-streams-interoperability https://nodejs.org/docs/latest/api/webstreams.html#nodejs-st... It's exactly the same story for crypto as well. Node created it's own standard, Web standards emerged, Node has to support both: https://nodejs.org/docs/latest/api/crypto.html https://nodejs.org/docs/latest/api/crypto.html https://nodejs.org/docs/latest/api/webcrypto.html https://nodejs.org/docs/latest/api/webcrypto.html Fwiw I think it's good they're not removing the legacy code, but they should probably do a big cleanup major release and lean into the modern standards and remove the old stuff. But there's obviously push back in doing so... and probably stuff you can do in the old modules that you can't do in the new and vice versa.
    - franciscop 27d ago
      Yes, I've dealt with streams a lot and I've seen the pain. I'd say it's the 2nd biggest "compat breaking" of Node/JS after the require vs esm, but while the require vs esm is mostly gone (we all use esm nowadays, except for aham the default npm) the stream types I expect will last for a long while since that's not so "high" in the productivity list for most. Also, that's actually one of the main pains I have with Node NOT supporting Fetchable, the fact that the Body is not a Readable. When we used to code by hand, Bun used to have an amazing list of articles on how to convert from almost any kind of streamable to almost any other type. I used it a lot, and that was when I started liking Bun so much.
- pjmlp 29d ago
  I wasn't even aware it exists, so no big problem.
- eudamoniac 28d ago
  It also doesn't support the foobaz protocols! But millions of companies are using it to serve millions of customers, and it's fine.

by domh 29d ago

hresvelgr 29d ago

It consolidates a lot of really annoying nits and quality of life aspects like bundling, module resolution, testing, env handling, etc. Node is just the runtime and still would require libs like esbuild, jest/vitest, dotenv, and so on. It's genuinely nice to have those out of the box, and generally in Bun the performance is quite significantly better in places that matter.

domh 29d ago
Let me address each one in turn: - esbuild - this is normally for TS compilation, which Node can run natively now by stripping types: https://nodejs.org/docs/latest/api/typescript.html#type-stripping https://nodejs.org/docs/latest/api/typescript.html#type-stri... - jest/vitest: Node has a test runner: https://nodejs.org/docs/latest/api/test.html https://nodejs.org/docs/latest/api/test.html - dotenv: Node can read .env files: https://nodejs.org/docs/latest/api/cli.html#--env-filefile https://nodejs.org/docs/latest/api/cli.html#--env-filefile Performance, maybe you're right - but if you're doing any IO, I doubt the runtime is really the bottleneck.

franciscop 29d ago

Node.js is virtually the only platform not supporting the Fetchable convention: https://github.com/nodejs/node/issues/63096 https://github.com/nodejs/node/issues/63096 https://fetchable.org/ https://fetchable.org/

domh 29d ago
That's a fair criticism... they move slower but mostly because they were the first. They would have to build a new Server and Request/Response primitives from scratch, or deprecate what they already have, or somehow shoehorn the existing types into the new ones. They do seem to have just merged in support for Web Workers though, which I've been following for a while: https://github.com/nodejs/node/issues/43583 https://github.com/nodejs/node/issues/43583 So I don't think they're opposed to standardising, but it's trickier when you have some past cruft built up. Lets not forget that the fetch() standard was built for browsers, and is a bit of a stretch to make it work on servers at all. You have to diverge from the fetch spec to even make it make sense in a server environment (with things like Cookies handling off the top of my head).
- domh 29d ago
  Same thing can be said about Streams in Node.js as well. They had a working streams implementation before the Web Streams API was in browsers (iirc). So implementing the standard now means removing what's already there, or breaking a lot of existing code. Which leads to confusing things like the fact that there are two streams APIs in Node now: Streams: https://nodejs.org/docs/latest/api/stream.html https://nodejs.org/docs/latest/api/stream.html Web Streams: https://nodejs.org/docs/latest/api/webstreams.html https://nodejs.org/docs/latest/api/webstreams.html And they have to support going back and forth between the two: https://nodejs.org/docs/latest/api/webstreams.html#nodejs-streams-interoperability https://nodejs.org/docs/latest/api/webstreams.html#nodejs-st... It's exactly the same story for crypto as well. Node created it's own standard, Web standards emerged, Node has to support both: https://nodejs.org/docs/latest/api/crypto.html https://nodejs.org/docs/latest/api/crypto.html https://nodejs.org/docs/latest/api/webcrypto.html https://nodejs.org/docs/latest/api/webcrypto.html Fwiw I think it's good they're not removing the legacy code, but they should probably do a big cleanup major release and lean into the modern standards and remove the old stuff. But there's obviously push back in doing so... and probably stuff you can do in the old modules that you can't do in the new and vice versa.
  - franciscop 27d ago
    Yes, I've dealt with streams a lot and I've seen the pain. I'd say it's the 2nd biggest "compat breaking" of Node/JS after the require vs esm, but while the require vs esm is mostly gone (we all use esm nowadays, except for aham the default npm) the stream types I expect will last for a long while since that's not so "high" in the productivity list for most. Also, that's actually one of the main pains I have with Node NOT supporting Fetchable, the fact that the Body is not a Readable. When we used to code by hand, Bun used to have an amazing list of articles on how to convert from almost any kind of streamable to almost any other type. I used it a lot, and that was when I started liking Bun so much.
pjmlp 29d ago
I wasn't even aware it exists, so no big problem.
eudamoniac 28d ago
It also doesn't support the foobaz protocols! But millions of companies are using it to serve millions of customers, and it's fine.