3 ms·

I said it back when Deno was released, and I'll say it again: I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature, and if you want pe

I said it back when Deno was released, and I'll say it again: I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature, and if you want performance, leave it behind for Go. It was telling when you saw that basically all of Deno's interfaces were inspired by Go. I'm so glad that as an industry we're saying "No," to all of these JavaScript authors who try to yank entire ecosystems along with them as they go try and monetize their spin-offs. I'm too busy shipping to care.

RainyDayTmrw 1y ago
I dunno. How much do you value isomorphism and code sharing?
- behnamoh 1y ago
  I legit read your comment as "I deno" :)
- deleted 1y ago
  [deleted]
josephg 1y ago
That’s fair but - I replaced node with bun a few months ago and I haven’t looked back. All my JavaScript projects run with no changes. Performance is on par or better compared to nodejs. It can run typescript directly without needing to be compiled. It also has a built in bundler & minifier (bun build), and some other goodies. The command line is a bit different - you need to “bun run” to run scripts. But eh. Nodejs still works fine, of course. But being able to run typescript directly is killer.
- croes 1y ago
  Wasn’t the USP of deno the baked in security features? How are bun and nodejs on that side?
  - nicce 1y ago
    Bun has segmentation faults regularly if you look issue tracker. Security is not there yet.
  - andrewmcwatters 1y ago
    I get the point of Deno's sandboxing, but at the same time, like, imagine writing software and not knowing whether your own code is secure because you're that reliant on downstream dependencies and have to update frequently because your dependency authors are constantly releasing enough that you have no confidence to say otherwise. It's just straight up not a problem other authors are thinking about regularly in other programming languages, because we don't have left-pad crises in other programming language ecosystems.
- curtisblaine 1y ago
  Node.js supports typescript out of the box by stripping types since node 22 (current LTS is 24, iirc) https://nodejs.org/en/learn/typescript/run-natively https://nodejs.org/en/learn/typescript/run-natively
theThree 1y ago
In web backend, Node.js is not slower than Go.
- danpalmer 1y ago
  [citation needed]
  - theThree 1y ago
    From my own testing. In high-concurrency scenarios, their performance is roughly the same, and Node uses less memory. When it comes to string concatenation, Go has to do a lot of extra work (no "+",Estimating string length, Preallocate memory ) just to catch up with the speed of Node (simply using "+").
- Aeolun 1y ago
  Eh, there’s some use cases where you can see some speedup from going to Go/Rust, but I’ll admit they’re pretty minimal.
- 9rx 1y ago
  Execution performance might be similar, but Node.js and Deno execution performance are also similar (both use v8 – there is only so much you can optimize beyond that), so clearly the comment is not talking about execution performance. Deno sells itself as having faster development performance, so presumably that is what performance is in reference to. It is hard to deny that Go isn't much more performant on the development end. Someone who is inexperienced might be slowed down due to that inexperience negating the performance boost, sure, but when one is concerned about developer performance they will be happy to incur the small upfront cost to become experienced for the bigger payoff later. (It is debatable if Go is really the king of developer performance, you might do even better with another language, but what is certain is that it is not Javascript/Typescript)
  - williamstein 1y ago
    For some applications especially those that benefit from cpu-bound parallelism, it is possible to write much faster code with Go than Node.js, e.g., consider the recent port of the Typescript compiler from Javascript to Go: - https://news.ycombinator.com/item?id=43332830 https://news.ycombinator.com/item?id=43332830
danpalmer 1y ago
> I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature I'm a bit of an outsider here, I've only run a little Node in production in the past, and used it on and off for ~13 years. My take is that these projects all get some hype specifically because Node.js is not mature. I've got a hobby project that has a bit of Node in it, and it very plainly difficult (Which imports am I using? Not the good one. Which language am I writing? Not the typed one. Which package manager do I use? etc). Getting a new project set up well takes time and effort, it is not the default that Node gives you (at least in ~early 2024 maybe?). I can really get behind the "not another JS rugpull" idea, but I also see why everyone is constantly wanting to get off Node itself onto something Node-like that solves their problems.
- andrewmcwatters 1y ago
  You avoid much of this by ignoring new things that are new for the sake of being new. Imports instead of require? Waste of time. TypeScript? Waste of time. Widely unpopular opinion. Package managers other than npm? Waste of time. Just ignore it all and you're fine. And definitely ignore the people who keep changing things on you. If it doesn't help me ship more product, I do not care.
  - danpalmer 1y ago
    Moving to Typescript may be unnecessary, but starting a brand new codebase in 2025 and using JavaScript instead of Typescript is a hard one to defend. The fact that Node.js doesn't support it out of the box, let alone encourage it as the default, is much of the reason why the community is constantly clamouring for something better.
    - curtisblaine 1y ago
      Node.js supports typescript out of the box by stripping types since node 22 (current LTS is 24, iirc) https://nodejs.org/en/learn/typescript/run-natively https://nodejs.org/en/learn/typescript/run-natively
    - andrewmcwatters 1y ago

RainyDayTmrw 1y ago

I dunno. How much do you value isomorphism and code sharing?

behnamoh 1y ago
I legit read your comment as "I deno" :)
deleted 1y ago
[deleted]

josephg 1y ago

That’s fair but - I replaced node with bun a few months ago and I haven’t looked back. All my JavaScript projects run with no changes. Performance is on par or better compared to nodejs. It can run typescript directly without needing to be compiled. It also has a built in bundler & minifier (bun build), and some other goodies. The command line is a bit different - you need to “bun run” to run scripts. But eh. Nodejs still works fine, of course. But being able to run typescript directly is killer.

croes 1y ago
Wasn’t the USP of deno the baked in security features? How are bun and nodejs on that side?
- nicce 1y ago
  Bun has segmentation faults regularly if you look issue tracker. Security is not there yet.
- andrewmcwatters 1y ago
  I get the point of Deno's sandboxing, but at the same time, like, imagine writing software and not knowing whether your own code is secure because you're that reliant on downstream dependencies and have to update frequently because your dependency authors are constantly releasing enough that you have no confidence to say otherwise. It's just straight up not a problem other authors are thinking about regularly in other programming languages, because we don't have left-pad crises in other programming language ecosystems.
curtisblaine 1y ago
Node.js supports typescript out of the box by stripping types since node 22 (current LTS is 24, iirc) https://nodejs.org/en/learn/typescript/run-natively https://nodejs.org/en/learn/typescript/run-natively

theThree 1y ago

In web backend, Node.js is not slower than Go.

danpalmer 1y ago
[citation needed]
- theThree 1y ago
  From my own testing. In high-concurrency scenarios, their performance is roughly the same, and Node uses less memory. When it comes to string concatenation, Go has to do a lot of extra work (no "+",Estimating string length, Preallocate memory ) just to catch up with the speed of Node (simply using "+").
Aeolun 1y ago
Eh, there’s some use cases where you can see some speedup from going to Go/Rust, but I’ll admit they’re pretty minimal.
9rx 1y ago
Execution performance might be similar, but Node.js and Deno execution performance are also similar (both use v8 – there is only so much you can optimize beyond that), so clearly the comment is not talking about execution performance. Deno sells itself as having faster development performance, so presumably that is what performance is in reference to. It is hard to deny that Go isn't much more performant on the development end. Someone who is inexperienced might be slowed down due to that inexperience negating the performance boost, sure, but when one is concerned about developer performance they will be happy to incur the small upfront cost to become experienced for the bigger payoff later. (It is debatable if Go is really the king of developer performance, you might do even better with another language, but what is certain is that it is not Javascript/Typescript)
- williamstein 1y ago
  For some applications especially those that benefit from cpu-bound parallelism, it is possible to write much faster code with Go than Node.js, e.g., consider the recent port of the Typescript compiler from Javascript to Go: - https://news.ycombinator.com/item?id=43332830 https://news.ycombinator.com/item?id=43332830

danpalmer 1y ago

> I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature I'm a bit of an outsider here, I've only run a little Node in production in the past, and used it on and off for ~13 years. My take is that these projects all get some hype specifically because Node.js is not mature. I've got a hobby project that has a bit of Node in it, and it very plainly difficult (Which imports am I using? Not the good one. Which language am I writing? Not the typed one. Which package manager do I use? etc). Getting a new project set up well takes time and effort, it is not the default that Node gives you (at least in ~early 2024 maybe?). I can really get behind the "not another JS rugpull" idea, but I also see why everyone is constantly wanting to get off Node itself onto something Node-like that solves their problems.

andrewmcwatters 1y ago
You avoid much of this by ignoring new things that are new for the sake of being new. Imports instead of require? Waste of time. TypeScript? Waste of time. Widely unpopular opinion. Package managers other than npm? Waste of time. Just ignore it all and you're fine. And definitely ignore the people who keep changing things on you. If it doesn't help me ship more product, I do not care.
- danpalmer 1y ago
  Moving to Typescript may be unnecessary, but starting a brand new codebase in 2025 and using JavaScript instead of Typescript is a hard one to defend. The fact that Node.js doesn't support it out of the box, let alone encourage it as the default, is much of the reason why the community is constantly clamouring for something better.
  - curtisblaine 1y ago
    Node.js supports typescript out of the box by stripping types since node 22 (current LTS is 24, iirc) https://nodejs.org/en/learn/typescript/run-natively https://nodejs.org/en/learn/typescript/run-natively
  - andrewmcwatters 1y ago