Deno 1.20
deno.com
Deno 1.20
1–10 of 60 posts
Re: Deno 1.20
#2Re: Deno 1.20
#3Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
Re: Deno 1.20
#4Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
Re: Deno 1.20
#5Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
Honestly not and for a simple reason: there is nothing in deno that I need and can't find in node, but there are a lot of libraries in node that I need and I can't use them in deno. Simple as that
Re: Deno 1.20
#6Earlier quoted context omitted.
Honestly not and for a simple reason: there is nothing in deno that I need and can't find in node, but there are a lot of libraries in node that I need and I can't use them in deno. Simple as that
Such as? Do you mean things in the standard library or like JS packages?
Unless you're writing a totally new application and don't need anything (even retrospectively) from NPM, Deno probably won't work for you.
As much as I like Deno as a concept, I can't really use it. Making a totally new JavaScript runtime with new API's and no compatibility with the current largest runtime is a very ambitious goal, and I hope they succeed with it nevertheless.
Re: Deno 1.20
#7Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
Personally I won't taking part in any node projects anymore.
Re: Deno 1.20
#8Earlier quoted context omitted.
Honestly not and for a simple reason: there is nothing in deno that I need and can't find in node, but there are a lot of libraries in node that I need and I can't use them in deno. Simple as that
Such as? Do you mean things in the standard library or like JS packages?
I tried to push through and port one of them, but the base Node Socket library was missing most of the methods.
Deno looks awesome though, I can’t wait to take another look when it’s a little more mature!
Re: Deno 1.20
#9Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
We moved our Deno project to Node because of lack of lower-level APIs on Deno's Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2]
RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base.
DevEx wise, Node is miles away from Deno, but it might get there in-time, or it might not [3]. I'd imagine, what may also work in Deno's favour in terms of IO-bound workloads, is the underlying tokio layer (vs libuv in Node).
API wise, Deno (comparatively) feels quite raw.
[0] https://github.com/denoland/deno/issues/13636
[1] https://github.com/denoland/deno/issues/9109
[2] https://github.com/nodejs/undici/issues/1203#issuecomment-10... | Explanation: https://github.com/RafaelGSS/nodejs-bench-operations/pull/3#...