3 ms·

What is the right recommendation at this point for a Node alternative? Deno?

by rao-v 2mo ago

tipiirai 2mo ago
I'm still waiting for v1.4 as I have committed to Bun so much. Not looking good, though.
xscott 2mo ago
Not that my opinion matters much, but I like Deno. I never tried Bun.
domh 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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.
rienbdj 2mo ago
What’s wrong with node? Genuine question
- tipiirai 2mo ago
  Nothing. Bun is just smaller and faster and comes with a built-in package manager, test runner, bundler, SQL engine, image processor etc..
- Mashimo 2mo ago
  I think npm install can be very very slow on large projects. Think minutes.
  - pjmlp 2mo ago
    Use pnpm or yarn, also available with node.
- kwhat4 2mo ago
  From the perspective of someone trying to package nodejs, building it is a complete dumpster fire. GYP (generate your projects) is a now defunct and poorly thought out build tool that node heavily relies on with it's native C/C++ modules. Cross compiling is completely broken and I am honestly surprised it builds reliability for the native target.
  - pjmlp 2mo ago
    C++ addons are great, that is what makes JavaScript on the server bearable, when performance matters and we're stuck with it, instead of using Go, Rust, Java, .NET.
- re-thc 2mo ago
  It's 1/2 baked in everything it tries to do. You need a "separate" tool called npm to install packages. It's dead slow so they added corepack. Another extra tool. Then you use it to install yarn or pnpm. Another extra tool. It might still be slower than bun... In the past you need to transpile typescript with other tools. It can only run js out of the box. The later fix was a wasm build, which means slower than it could be. Another 1/2 job. Many more examples in many areas but anything Node tries to do itself feels 1/2 baked. Bun and Deno are faster than Node because it is a 1/2 job at its core. It has v8. It has the tools. It could be done but no. It did nothing for years until Deno and Bun came on the scene to nudge it.
verdverm 2mo ago
imo, node is fine, they have done a lot to improve and the menagerie of js runtimes have largely converged
pfzero 2mo ago
But why do you need an alternative to node in the first place?
spartanatreyu 2mo ago
Deno, it has a standard library and a security model.

What is the right recommendation at this point for a Node alternative? Deno?

by rao-v 2mo ago

What is the right recommendation at this point for a Node alternative? Deno?

tipiirai 2mo ago

I'm still waiting for v1.4 as I have committed to Bun so much. Not looking good, though.

xscott 2mo ago

Not that my opinion matters much, but I like Deno. I never tried Bun.

domh 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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.

rienbdj 2mo ago

What’s wrong with node? Genuine question

tipiirai 2mo ago
Nothing. Bun is just smaller and faster and comes with a built-in package manager, test runner, bundler, SQL engine, image processor etc..
Mashimo 2mo ago
I think npm install can be very very slow on large projects. Think minutes.
- pjmlp 2mo ago
  Use pnpm or yarn, also available with node.
kwhat4 2mo ago
From the perspective of someone trying to package nodejs, building it is a complete dumpster fire. GYP (generate your projects) is a now defunct and poorly thought out build tool that node heavily relies on with it's native C/C++ modules. Cross compiling is completely broken and I am honestly surprised it builds reliability for the native target.
- pjmlp 2mo ago
  C++ addons are great, that is what makes JavaScript on the server bearable, when performance matters and we're stuck with it, instead of using Go, Rust, Java, .NET.
re-thc 2mo ago
It's 1/2 baked in everything it tries to do. You need a "separate" tool called npm to install packages. It's dead slow so they added corepack. Another extra tool. Then you use it to install yarn or pnpm. Another extra tool. It might still be slower than bun... In the past you need to transpile typescript with other tools. It can only run js out of the box. The later fix was a wasm build, which means slower than it could be. Another 1/2 job. Many more examples in many areas but anything Node tries to do itself feels 1/2 baked. Bun and Deno are faster than Node because it is a 1/2 job at its core. It has v8. It has the tools. It could be done but no. It did nothing for years until Deno and Bun came on the scene to nudge it.

verdverm 2mo ago

imo, node is fine, they have done a lot to improve and the menagerie of js runtimes have largely converged

pfzero 2mo ago

But why do you need an alternative to node in the first place?

spartanatreyu 2mo ago

Deno, it has a standard library and a security model.