Has 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
Probably both. You can't use NPM (though you can use one of those online CDN's like unpkg) and the packages you can use probably don't work, as Deno doesn't support Node's API at all. It doesn't support any Node-specific packages like 'fs' or 'crypto' either.
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.
You might want to consider giving Deno another shot, as they've spent a lot of time on building node comparability since v1.15 specifically to address these problems.
Many of the APIs you mentioned are supported already, while a few require the unstable flag...
It's a pretty ergonomic way of scripting smaller tasks, at least. The first time picked it up for the sake of a meaningful experiment I stopped short of actually deploying a full project on it -- the key limitation being that I couldn't find anything comparable to Mongoose -- but did end up building a companion tool that turned out to be pretty useful, and for stuff like API calls and bulk file manipulation I would reach for it every time.
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.
What kind of problems did you encounter ? I recently switched from v12 to v16 without any problems on a decent sized project. I was expecting to break a few things and surprised how smooth it all went.
Maybe someone working with a library project can answer that. Trying to replace node with deno in e.g. React + NPM project might be way too complicated.
Personally I won't taking part in any node projects anymore.
> ...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).
If anyone wants to work on this (make web streams faster in Node) it'd be welcome. The main reason web streams are slower in Node is a lot less work has been put into making them fast. They're mostly seen as an interop layer.
I think it could make sense to implement lower-level APIs in Rust and then expose higher level APIs to JavaScript so that connections to upstream services can be shared across a pool of JavaScript Workers.
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.
Not switching from Node, but I've been building some Typescript libraries that are mainly for the browser and when building command line app versions for them, Deno worked out of the box while Node has hiccups (no Fetch, no Websockets, etc) and since Deno works so well I just never added Node support.
Small aside: if you ever plan on doing Deno-first libraries, https://deno.land/x/dnt@0.20.1 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.
I'm an existing typescript user but I just can't see a reason to use Deno.
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.
> 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.
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.
> No, this is the gatekeeping mentality of many people software development.
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).
"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"
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.
> That sounded a bit like the "imigrants stealing our jobs" argument.
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.
> 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.
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.
Not an affront; we just seem to have a surprisingly different notion of a React bootcamp graduate. It requires both the respect for web standards and the annoyance with Node's quirks to have an appreciation for Deno, neither of which a recent React bootcamp graduate would have had the time to cultivate. Whereas, since such hypothetical graduate is more likely to be in search of immediate practical in-demand skills, they would be more likely to pick Node over Deno as a much more popular option. Plus, they would be likely to have been exposed to Node during their bootcamp training, by running webpack, create-react-app, and suchlike.
I haven't done an existing project yet, but based on some experiments it seems like I'd mostly be deleting configuration files and making an import map. A simple SPA is crazy easy in deno: https://github.com/baetheus/deno-spa-example/
I've switched a few projects back and forth but I am on the more experienced side (I'm comfortable with both codebases and have 2 digit commit numbers in both projects).
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.
I love working with JS/TS (front, back, tooling), but find Node more and more annoying (especially bothered with packaging a release for production, lately).
So naturally I tried Deno lately.
Some things mentioned in other comments were really nice, but the lack of retrofit with the Node ecosystem is a shame. So many years and efforts and community growth are sitting right next door only to be ignored...
I haven't used Deno myself yet but I'm very interested. Deno has a whole section about Node interoperability in their manual that makes it seem like you can use Node packages, but I have yet to test that out myself. Curious if anyone else has
Looks promising and I find the Deno project very exciting!
What is the recommended way of running Deno in production on a multi core machine? In node there is the cluster module that allows one process to run a cpu intensive task while the other processes to continue answering web requests.
This is good for stuff like excel exports as an example on larger datasets. Obviously you could run some kind of cronjob in the background but it seems like I may a bit confused about Denos architechture regarding this subject. I am afraid of switching to Deno because of this since I often want to do these kind of operations without having to do the hassle of breaking the app up for simple exporting/importing operations.
Also, will Deno really utilize other cores on the machine? It seems like if you have a machine with multiple cores Deno won't use the full potential of the hardware or am I just confused about this subject?
Deno does expose the "Web Workers" standard as a way to utilize multiple cores, where communication between them is handled by postMessage(...).
However, afaik, things like sockets can't be passed through (something node can do iirc).
There is a mechanism for this in the web workers spec; Transerables, that's part of the web API spec and is used to allow passing things like a large ArrayBuffer from one worker to another without needing to copy it by removing access from the sender and giving it to the receiver.
So you would have to plumb the socket into postMessage for a worker, or, for the excel example, make use of promises/async+await to spin up a worker, feed through the min. data needed to kick off the export, let it process in the worker and then send the response back to the main thread.
Yes I am aware of that and sure it can be used for export/import like I described. But it won't answer the second part of my question, about Deno not utilizing all cpu cores on a multicore machine?
If I use a web worker it will be for one specific thing and that thing only, not for the entire web request? Thus, if there is anything slowing down the request in form of CPU intensity, it will "kill" the application at least until the cpu intensive request completes.
Sometimes it's hard to know beforehand what users do for example and surprising things can happen. I have had the same issues with Meteor for example where users killed the app because they tried to upload something unexpected that crashed the app and them spamming the upload button kept it crashing after restarts. It was of course an error from my part but it could be avoided if Meteor did support the cluster module. I have also had the exact same issue when unexpected large datasets occurred by user input (not file uploads), the app got so slow it stopped answering requests from other sources. It was after that I discovered that pm2 can run any node app in a clustered mode, which was very nice.
But with that experience in my baggage, it am very hesitant to use Deno because of this reason. I can't host my app on a serverless platform because reasons and I am not sure I even want to even if I could.
Really what your asking is a framework level query rather than what low level primitives the runtime provides.
Demo itself won't use all the cores for some JS you just slap in, that's not how JS works (it'll use the same as v8, which will be one main thread for the JS to be processed in and potentially several helper threads for IO etc)
If you want multi core you either build it yourself using the web workers or find a framework that does it for you.
I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it.
Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any programming related stuff. Performance on the other hand is what people talk about. But nobody cares about performance irl.
It won’t take long to get it popping. You just need a few tech blog posts from well known startup with a headline that reads ‘How we switched from Node to Deno’, and voila, the snowball just got rolling.
It is about ability to find talent who does not have to figure out everything not really about copying.
Only few companies have the budgets, talent and the motivation (do cool new things and blog) to experiment with drastic changes like deno.
Rest of us can only afford to maybe try once they do make it popular and there is enough material online SO/GitHub projects /libraries/blog posts to learn from someone else's experience.
Most engineering teams cannot afford to be trailblazers
My personal prediction is that Deno is never going to take off. It's just not a significant enough improvement over Node.js that abandoning the existing ecosystem is worth it.
Deno is betting on edge computing to explode and offers a good offering (Deno Deploy) in that space leveraging how it has a smaller API and faster startup times than Node.
It also thinks that edge computing is a good space to leverage the myriad of web APIs it supports + there are certain workloads that it does better than Node (like single executable)
I think they will slowly close the functionality gap until Deno does the most common 80% of stuff Node does.
Then you factor in how Deno will be fundamentally more performant - we will see large companies who can't squeeze another cycle out of Node write blog posts about how they switched to Deno.
And lastly, NPM is a tire fire. The left-pad and faker hits will keep coming, on top of an almost daily procession of new security vulnerabilities in deep dependency trees. Something so bad could happen here that ppl sour on Node.
So I think Deno stands a chance. They just need to keep implementing and bide their time. A moment could come.
I have moved all my library development to Deno and described the experience in a blog post[1].
To summarize, the two killer features for me are Web APIs and the built-in toolchain.
I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My last straw was trying to run Jest tests on TS code compiled into a Node.js ESM module. I believe I spent more time figuring out workarounds for a myriad of issues in Jest+ Node+TSC chain, than it took me to switch to Deno where all of it came out of the box.
To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.
We can still appreciate that Deno puts some "pressure" on Node to continue improving and to copy any good idea Deno might introduce, which is a net win for everyone, even if most people continue using Node.
I was a little confused at first, but I think you mean “killer features”. “Killing features” is not idiomatic, and has kind of the opposite (i.e. negative) connotation
thanks for posting this. Much needed.
When you said:
> The process of reconciliation has been slow and painful, cue ESM modules.
I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development mode it is expecting .ts files), however that breaks when the same code is run on the client side or production mode when it is tsc. How is Deno dealing with this issue? Does Deno just compile all the code to work in broser, serverside typescript all together?
Yes, TS code is compiled to run in browsers. You can compile and bundle using `deno bundle` if your project is developed in Deno. Since I'm using Deno for library development, I use the `dnt`[1] tool to compile them into ESM modules later consumed by esbuild in my Node-based projects/toolchains.
As a hobbyist, Deno is actually quite nice, and is definitely a good way to learn JavaScript these days. TypeScript support is icing on the cake. Sure, you don't have access to years worth of Node packages, but I can overlook that when programming solo with it is generally nicer than using Node.
The task runner is a welcome addition. It will be a lot like node, except hopefully more Deno devs than node devs will have the good sense to put complex things into a separate program. The permission system will also help make sure a task is only doing what it needs to do. For instance, https://nextjs.org/telemetry tracks calls to each command, including build.
Deno sounds neat to me but last I tried, I get the impression that it's better than Node in areas that doesn't really matter. Some thing are really annoying to deal with which are easy in Node. The other way is true where Node sucks on some part that Deno are great at. But I found it much easier to find workarounds in Node than Deno.
I do hope Deno keeps improving though. Always good to have alternatives!
59 comments
[ 2.4 ms ] story [ 122 ms ] threadUnless 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.
Personally I won't taking part in any node projects anymore.
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#...
[3] https://www.youtube-nocookie.com/embed/M3BM9TB-8yA
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/dnt@0.20.1 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.
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
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?
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.
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.
So naturally I tried Deno lately.
Some things mentioned in other comments were really nice, but the lack of retrofit with the Node ecosystem is a shame. So many years and efforts and community growth are sitting right next door only to be ignored...
I can't understand that.
https://deno.land/manual@v1.20.1/node
What is the recommended way of running Deno in production on a multi core machine? In node there is the cluster module that allows one process to run a cpu intensive task while the other processes to continue answering web requests.
This is good for stuff like excel exports as an example on larger datasets. Obviously you could run some kind of cronjob in the background but it seems like I may a bit confused about Denos architechture regarding this subject. I am afraid of switching to Deno because of this since I often want to do these kind of operations without having to do the hassle of breaking the app up for simple exporting/importing operations.
Also, will Deno really utilize other cores on the machine? It seems like if you have a machine with multiple cores Deno won't use the full potential of the hardware or am I just confused about this subject?
However, afaik, things like sockets can't be passed through (something node can do iirc). There is a mechanism for this in the web workers spec; Transerables, that's part of the web API spec and is used to allow passing things like a large ArrayBuffer from one worker to another without needing to copy it by removing access from the sender and giving it to the receiver.
So you would have to plumb the socket into postMessage for a worker, or, for the excel example, make use of promises/async+await to spin up a worker, feed through the min. data needed to kick off the export, let it process in the worker and then send the response back to the main thread.
If I use a web worker it will be for one specific thing and that thing only, not for the entire web request? Thus, if there is anything slowing down the request in form of CPU intensity, it will "kill" the application at least until the cpu intensive request completes.
Sometimes it's hard to know beforehand what users do for example and surprising things can happen. I have had the same issues with Meteor for example where users killed the app because they tried to upload something unexpected that crashed the app and them spamming the upload button kept it crashing after restarts. It was of course an error from my part but it could be avoided if Meteor did support the cluster module. I have also had the exact same issue when unexpected large datasets occurred by user input (not file uploads), the app got so slow it stopped answering requests from other sources. It was after that I discovered that pm2 can run any node app in a clustered mode, which was very nice.
But with that experience in my baggage, it am very hesitant to use Deno because of this reason. I can't host my app on a serverless platform because reasons and I am not sure I even want to even if I could.
Demo itself won't use all the cores for some JS you just slap in, that's not how JS works (it'll use the same as v8, which will be one main thread for the JS to be processed in and potentially several helper threads for IO etc)
If you want multi core you either build it yourself using the web workers or find a framework that does it for you.
I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it.
Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any programming related stuff. Performance on the other hand is what people talk about. But nobody cares about performance irl.
Copy cat culture will do the rest.
Only few companies have the budgets, talent and the motivation (do cool new things and blog) to experiment with drastic changes like deno.
Rest of us can only afford to maybe try once they do make it popular and there is enough material online SO/GitHub projects /libraries/blog posts to learn from someone else's experience.
Most engineering teams cannot afford to be trailblazers
It also thinks that edge computing is a good space to leverage the myriad of web APIs it supports + there are certain workloads that it does better than Node (like single executable)
Then you factor in how Deno will be fundamentally more performant - we will see large companies who can't squeeze another cycle out of Node write blog posts about how they switched to Deno.
And lastly, NPM is a tire fire. The left-pad and faker hits will keep coming, on top of an almost daily procession of new security vulnerabilities in deep dependency trees. Something so bad could happen here that ppl sour on Node.
So I think Deno stands a chance. They just need to keep implementing and bide their time. A moment could come.
To summarize, the two killer features for me are Web APIs and the built-in toolchain.
I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My last straw was trying to run Jest tests on TS code compiled into a Node.js ESM module. I believe I spent more time figuring out workarounds for a myriad of issues in Jest+ Node+TSC chain, than it took me to switch to Deno where all of it came out of the box.
[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...
edit: spelling
I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development mode it is expecting .ts files), however that breaks when the same code is run on the client side or production mode when it is tsc. How is Deno dealing with this issue? Does Deno just compile all the code to work in broser, serverside typescript all together?
[1] https://github.com/denoland/dnt