Home
Starting Up
Case Studies DB
Products
Ideas DB
Vibe Coding Tools
Subscribe to IH+
Starting Up
Case Studies
Ideas DB
Products DB
Join
5
Likes
16
Comments
Will deno replace node.js?
by
NavehMevorach
If you think that It will replace node,
What business opportunities do you think will pop up?
I've been a sever side JavaScript developer for about 5 years. Node is great. It has its drawbacks and npm has its problems, but much of that has improved greatly over the years.
But when it comes to Deno, I see almost no benefit over Node. I find the three main value propositions to be a little odd.
Runs TypeScript out of the box.
Okay... But why is that a benefit? It's super easy to use TS in Node with very little additional config. Why are we putting the runtime in charge of TS? It also forces you to use TS, which I think makes initially learning JS more difficult.
It runs on Rust.
Trendy. But is it really much more than that? The language that something is written in doesn't make it or break it. A safer language doesn't guarantee safety. It just makes it easier. Node has been around and stable a whole lot longer so I'm going to bet on its stability.
More "secure" like the browser (i.e. you have to specifically let it use things like network and file access)
Except for a few very limited use cases, I only see this as an annoyance and not much of a benefit. Why should sever-side JavaScript be more like the browser in this way? As far as I know, no other sever-side language does this sort of thing. It just feels very out of place.
With those in mind, and the fact that Deno largely abandons the massive existing Node ecosystem, I just don't see Deno gaining too much ground. Right now its trendy and cool so people are talking about it. I'm sure there will be use cases where it is better. But I don't see it surpassing Node.
Just wanted to mention that Deno doesn't force you to use TypeScript, you can just use regular JS.
Oh, really? I was under the impression that you have to use TS. I'll have to check.
But regardless, it is just transpiling the TS on the fly. Like ts-node. So I don't really see a benefit there.
No, because it is a lot slower.
Personally i have given Deno a lot of thought Serverless wise. The way that it is built security wise i think it has a strong position to be viable for a serverless platform.
Well... I don't own a crystal ball.
NodeJS is already well implemented. Deno is "just" at the starting position.
You've tons of packages available through NPM, when you don't have a lot (for know) with Deno.
The question is not "Is Deno going to replace NodeJS", but "What Deno will be more useful at".
Deno is, for example, easier (in my point) when you want to deploy ASAP a light server that serves RESTful API.
Actually I understood that you can use nodejs packages on deno.
I agree that for now it better for a light server but I'm sure that in the next version it will be great for everything
You can use some Node packages in Deno. But not all. https://stackoverflow.com/questions/61821038/how-to-use-npm-module-in-deno/61821141#61821141
Do you find any important one that not supported by deno?
I've not used Deno beyond simple examples, so no.
You know what's funny?
Deno is trying to turn Node into a proper backend tool, something that other languages have been doing from the start. So, I'm greatful that the creator of node has realised and admitted to how flawed node actually is.
Node has a massive following, I'm not always sure why, but that is that. When a language and framework goes that big, it doesn't go away. Same as how Java and PHP are still being used, JS/TS and Node will probably be here until we all live on mars.
What's wrong with Node as a "proper" backend tool that Deno solves?
I like that deno has a bigger focus on security and that it is not so dependent on npm. (npm is rather dangerous :D)
Built for single core, everything you do is a promise or a async/await which adds so much code. Most other languages do things in order, only requiring extra code config when needing multi-threads.
Then the biggest danger with node is that it doesn't gracefully fail.
I've tested python, rust, Golang and Node head to head as I do a lot of APIs.
Javascript is the only on that Fails catastrophically under high loads.
While the other languages execute every request, no matter how long it takes, javascript loses the plot completely by throwing away requests it can't handle.
So, technically, deno is trying to pollish a *** unfit backend tool ***
Don't get me wrong, I like JS/TS node for certain tasks, just not all.
I try to choose the best tool for the job rather than doing the job with a tool because that's the only one I know.
Thanks for going into detail 😀
Deno's solution for package management actually kinda scares me. Rather than dealing with npm's problems, they just offload them to you. Importing code from any random website, while maybe sounding good cause it isn't centralized, sounds pretty dangerous to me. Now you have to hope that every single site that you get code from is trustworthy and has appropriate security.
Also, managing package versions from a non-central location sound like a nightmare 😬
npm definitely has problems but, from what I can tell, Deno's solution doesn't seem to actually solve them.
Node can definitely learn from some of Deno's improvements, and hopefully, also improve. But I would hate to see the JavaScript ecosystem split between Deno and Node. Especially since they aren't fully interoperable. Its a step back from a more universal JS, not a step forward, imo.
Cool beans.
I think the URL import will work fine. The standards are still to be set, but think like this, https://premium-packages.com/v2.4/package.js
Once you built your code to V2.4, it stays that way until you change it.
That only brings in one file. Yes, you have to still look at what's happening in that file. You definitely have to look at what's happening inside npm imports too, as they are notoriously sketchy. So it's same/same, but maybe will get better.
I wanted to build a basic 3 page website the other day, and after npm ran the first time, I had 1 gig and 22 000 files in the directory.
I'm not reading all of that!!!!!
I agree, there are already too many environments out there already, we don't need another split.
I think that in an ideal world, a common tool is a good thing, as everyone learns the same tool. But, that tool has to be proven to be the best.
The real question is why it became so big