Node's package management has many, many issues in my opinion, one of these issues being that it is centralized. All node packages, or at least a very large percentage of them are hosted/stored on npm, while this is a good thing in some viewpoint, this also means, if for whatever reason npm goes down, we have no way of downloading/fetching packages our projects may need.
Deno fixes this by allowing packages to be hosted in a non-centralized manner, packages are stored on websites such as GitHub, pika.dev, etc, and then mirrored onto their third party listing page at https://deno.land/x. This approach means that if for whatever reason a platform goes down, there is still ways to fetch the needed dependencies.
Another thing Deno fixes is the extremely large package folder node has called
node_modules, deno does not have a modules folder, nor does it have anything like
package.json, instead modules are cached globally at a directory pointed to with the environment variable
DENO_DIR, and instead of downloading packages through a package manager, the deno runtime handles it, itself.
To add a dependency in Deno, all you do is link a URL to the module you want to use, and then use it in your code, as such:
import * as fmt from "https://deno.land/[email protected]/fmt/mod.ts"; console.log(fmt.green("hello!"));
Node has had many, many instances of packages being exploited, or taken-over and used for malicious purposes, an example of this being the nefarious 1337qq-js package, read about that here. This is fixed with how Deno packages are hosted on decentralized environment, such as GitHub.
Another thing worth noting, is Deno is built to be secure, with deno applications/scripts can do literally nothing except maybe print something with
console.log by default. If you want a script to be able to write files, you have to enable
--allow-write as a flag, what about read?
--allow-read, so on and so fourth, all permissions must be explicitly granted, meaning it's a lot harder for packages to exploited or used for malicious purposes.
While you have to use the
node-typescript to execute scripts outright, with Deno this is not needed as the Deno runtime has first class support for TypeScript, and can compile and run it out of the box.
Node has many, many tools, Jest, Eslint, Prettier, the likes, however they are all seperate, and you have to manually install them. In Deno this is not an issue, as they aim to, and are so far doing well with the idea, that everything is built into the runtime itself, want to format code?
deno fmt mod.ts done, want to get information on dependencies?
deno info mod.ts done, so on and so fourth.
In the end it's a matter of standards, time, and evolution of the languages and runtimes, as of the current time I use both runtimes, as Node satisfies some needs, while Deno satisfies others, however, at some point in the future, I could honestly see Deno being on top with enough time and effort, and evolution of the runtime.