I must clarify some points:
1) I am not against NodeJS. NodeJS will always have a special place in my heart, because I wrote my first server in (pure) NodeJS and I learned a lot about http, etc..
2) I moved to Deno because I thought "Hey, the smart guy that created NodeJS (and left the project - something I never understood) is back on the saddle again! Probably Deno will be a better NodeJS.". Moving to Deno was in part my way to express gratitude.
3) In no way I am telling people to leave NodeJS (you may include NPM). I think that one chooses what is good for him. In my case, it was easy to make the move.
4) I totally agree with you about the risks of adopting a software that was created "yesterday". But NodeJS is a success, mature, today because in the past, people embraced it when it was immature. The same process may be happening to Deno.
5) Comparing the mechanics of the package managers (or whatever Deno has): my main concern about NodeJS/NPM was always lack of authorithy: for example, someone to define that Express is the official/standard framework. The role of the community should be helping improve the standard and also freely create alternatives (I think Go works this way). Obviously if Deno doesn't define standards, we will have the same problems as we have with NPM.
6) I moved to Deno prepared to face bugs, problems in the implementation. But I was not expecting some design decision inferior to NodeJS, IMHO. I found a small issue and complained:
"existsSync crashes on long path #9365"
https://github.com/denoland/deno/issues/9365
First, existSync is not a built-in. And I think it should be because one of the goals of Deno is using the REPL to replace Bash commands. So in the REPL it is a bit cumbersome to write
import { existsSync } from "https://deno.land/std@0.85.0/fs/exists.ts"
exists and existsSync return true or false acording to the existance or not of the file or directory. When you call them giving a very long path (so long that is invalid) as argument the result is:
NodeJS -> false (of course, the path could not exist!)
Deno -> raises an exception (breaks the execution if not done inside a try/catch block)
Well, the folks at Deno replied that this behavior is not a flaw. That it works as designed. I was disappointed. The way it was designed seems unecessarily (at first sight) complicated and counterintuitive. It does not fit well inside the REPL.
7) Maybe Deno has too many goals and trying to achieve all of them generates conflicts. For Deno it is not good enough to be JavaScript. It wants to provide all the browser functionality in the server code. JavaScript is bloated. The browser is a GUI, Deno is a CLI. Maybe Deno will become a bit messy.
8) Finally. I moved to Deno. And I am still testing it.
