Ask HN: Why Didn't Deno Gain as Much Popularity as Node?

Node was something new, that hadn't been done before and was easy to use, it meant that you could use Javascript on the front and backend, so you didn't need people with experience in PHP/Java/C# to write your backend code. You could reuse functions.

But when Deno came out, it was basically seen as an improvement on Node that wasn't entirely compatible with it. You couldn't just switch `node run` to `deno run` and have it work. Node has the critical mass of modules that Deno doesn't, and people already have a lot of experience with Node.

Basically, people just think Node is good enough and Deno doesn't offer enough to bother switching.

Some ideas in no particular order:

- Node is still around and still used, so there's less room for Deno unless Node decreases

- Deno fills a slightly different position than Node, in that it's a TypeScript engine and is more aligned with modern JavaScript how it runs in browsers, allowing you to share more code between browsers and Deno than you can between browsers and Node

- Deno users are probably almost all also Node users, while not all Node users may be Deno users

- Some of the people who might be interested in Deno compared to Node may also be interested in other runtimes like Bun and QuickJS

I don't think the size or popularity of Deno are a problem and I think more and more people will enjoy it in the future as time goes on.

Deno offered too little too late.

Performance? It wasn't faster and potentially slower until quite very recently when Bun entered the game. Even today it isn't really faster especially on the compatibility layer.

Security? It brings that up a lot but do you use it? Client side? Languages like Java also had a security manager in which it is dropping because of low usage. No 1 really manages security at this layer anymore.

Integration? Yes you have Typescript etc out of the box but with no compatibility and libraries, does it really save you time? Bun did all of it but with compatibility. Deno more recently had to go back to building compatibility with node.

And Deno just didn't have the marketing budget like Vercel to push it. People tried it, realize they couldn't do certain things e.g. connect to the database via ORM and gave up.

Too much stuff in the nodejs ecosystem is based around the premise that there is something fundamentally wrong with node and npm. They have room for improvement sure but they're not so broken I'm going to bother swapping out core components and bet on their long-term support and stability and compatibility and commit to their opinionated choices and idiosyncrasies. It's even worse when you get into the build tools and frontend libraries, bottom-to-top you can add a whole lot of unnecessary baggage to be mindful of and it's tiring, it's like decision fatigue but worse because every decision carries a bunch of responsibilities for everyone else working on that code.

I tried Node in the early days and hated it. Nor did NPM gell for me.

So when Ryan Dahl explained his reasons for Deno, I felt that the project addressed many of my dislikes of Node. Seems to me that for the majority of Node users, the switching costs don't compensate sufficiently for the improvements. Deno has slowly improved its backward compatability with Node. I am in no position to pass judgement on that.

Then Bun was released. It is more performant and more focused on Node compatability.

I use both Bun and Deno for my projects. Since I use Chrome mostly, being able to debug with DevTools makes me prefer Deno.

In summary, we have a choice of 3 great environments. Aren't we spoilt?

Why is everything so far in this thread worded in past tense? It feels like you're all talking about a long closed chapter of history.