I think you should look at it the other way around, assuming you are already using a mature version of Deno it most probably wouldn't make sense to switch to so

I think you should look at it the other way around, assuming you are already using a mature version of Deno it most probably wouldn't make sense to switch to something like NodeJS: - Why using CommonJS over standard ESM modules? - Why using a package manager like NPM? Browsers don't have package managers, my code can run on the client without something like NPM, why should it be any different on the server? - Why having callback-based APIs in a world of promises and async/await? - Why having node-only APIs when today standardized browser equivalents exists? - For better or for worse as far as I'm concerned TypeScript is the de-facto successor of JavaScript, especially if you need to work on big codebases. Flow is irrelevant outside of Facebook. If something better pops up Deno could adopt that too or you could just compile that to JS yourself and Deno would work with it already. As things stand currently other compile-to-JS languages are way less important than TS. - Servers aren't the only kind of application that can be written on top of Deno, why on earth would I want eslint to be able to have access to the network or spawn child processes? Or even have global read/write access to my whole disk? Deno's model is a much better default than Node's from a security perspective. You can't even install something from NPM with reasonable certainty that that won't nuke your computer. Essentially switching from Node to Deno may not seem like an obvious improvement, but it is in many ways, switching from Deno to Node has only drawbacks basically, if you don't consider Node's advantage in ecosystem size I can't imagine why anybody would switch from Deno to Node in the future.