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#...
When running NodeJS at scale we had to add proxy servers to pool connections to upstream services which had been designed for smaller numbers of more highly utilized connections from large multithreaded Java application servers.
Small aside: if you ever plan on doing Deno-first libraries, https://deno.land/x/[email protected] is a library that takes a Deno project and builds an entire Node project with shims (sadly only for Deno-specific stuff, so no node-fetch or ws) so you can publish to NPM.
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.
Many of the APIs you mentioned are supported already, while a few require the unstable flag...
https://deno.land/std/node/README.md
In my experience I've been able to use many node packages unmodified recently.
Well… the current largest runtime is web browsers and Deno has a much better story there than Node does. But agreed, it’s a long road ahead.
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!
Specifically, it was a minimal simfile parsing/conversion/seeding tool, as part of a DDR workout tracker I was working on a while ago. (Everything from COVID to a mouse problem in my workspace kind of undercut me doing the cardio I had built it to track, so it sort of stagnated :-/ But the tooling itself was pleasant enough here.) Basically it had three core pieces of functionality:
- Parsing .sm files and converting them to .ssc (the former doesn't label its fields, so doing this first simplified everything else)
- Extracting metadata from simfiles in .ssc format and exporting it to JSON
- Uploading extracted metadata to the accompanying API
This is something of a moot point since it's been added to Node now, but at the time having access to server-side `fetch()` also saved me some frontend work, because then all of my client-side requests became isomorphic and I could just mock out what I was eventually going to need for my UI without actually having to make any other decisions about how the UI was going to be structured.
My motivation for Node was that Deno's instrumentation/APM story doesn't exist which is a show stopper for many production apps and a lot of stuff was missing.
My motivation for Deno was trying out deploy (their edge computing offering) which is really cool.
Personally I won't taking part in any node projects anymore.
Depending on the NPM repository CDN is less worrisome than depending n different CDNs.
Including all my dependencies unilaterally (aka deps.ts) seems like a patch upon a bad decision.
Making the server side runtime environment pretend to be or adopt aspects of the web browser client environment seems like a misguided direction in my wisdom, because it compromises the whole runtime and you it'll always eventually fall short, as everything that copies does.
With everything going toward serverless, support there is essential and Deno just doesn't have it.
Lack of backward compatibility with other libraries means an uphill struggle, likely resulting in a lot of ported and unmaintained packages.
I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development.
For all these reasons, I regard Deno as dubious for now. I say all of this narrowly through my own experience and perception.
This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack.
Deno is more appealing to seasoned web developers, who appreciate its conformity to modern web standards, the absence of Node quirks, and a better security.
Example: discussion of Deno by two Google developer relations engineers: https://www.youtube.com/watch?v=SYkzk_j3yb0
It appears you've received this as some sort of afront. Everyone looks for a wave to ride toward the future and riding a wave is not undesirable. The Node wave has broken and is coming to a rest, slowly over time. Deno is a motion to create another. That's the natural order of things and it's okay.
> Deno is more appealing to seasoned web developers, who appreciate its conformity to modern web standards, the absence of Node quirks, and a better security.
It's interesting isn't it, because I offered my thoughts as someone who could be described as a seasoned web developer - they were just not the same as yours today.
No, this is the gatekeeping mentality of many people software development.
It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
I sense that I've touched a nerve and I'm sorry for that. May I ask what you believe I'm gatekeeping?
> It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
Could you offer some examples, so that I can learn?
I would agree with your statement that Deno removes idiosyncrasies of server-side JavaScript, but that's when viewed from a front-end-first perspective (ie. the predominant and perfectly reasonable perspective of code camp graduates that I've worked with).
That sounded a bit like the "imigrants stealing our jobs" argument.
"Deno removes idiosyncrasies of server-side JavaScript, but that's when viewed from a front-end-first perspective"
Not just the frontend perspective, but also the ECMAScript perspective, in which even Node.js creators participate.
I see that, thank you. Perhaps it would have helped if I'd added the word "experience" to the end.
I sense that Deno is primarily being pushed by developers who [graduated from] React-based code camps who are (understandably) looking for a wave to ride [toward] "full stack" software development [experience].
> but also the ECMAScript perspective, in which even Node.js creators participate.
Could you point me to concrete examples?