Deno's API is built to follow the browser's API. This means that developers can easily go between the two. It's also a big gesture to align with the Web Standards. Rather than invent something different. Deno supports the web community by building on top of it
Decentralized Packages
Using URLs for packages also aligns with the web. URLs are what the web is built upon. So it makes sense to align with that also. Plus the GoLang community uses this method. So it's battle-tested.
Breaking Change From Node
Deno offers a similar development experience but with the opportunity to start fresh. The community has matured a lot since Node.js was created. All that experience can be brought into Deno to make better decisions for the future.
Mascot
Deno the Dinosaur is cute. That's +1 over Node.js ;)
Also, just to be clear. I love using Node.js. Just excited that Deno builds on what was amazing about Node.js and makes it even better.
One problem with using url for importing package is that it mix the concept of package location and package name (where it being referenced in the code). You'll start discover this problem when you want to change where the package come from (for example you have to fork some package into your own repo) but don't want to change the source code to refer to the new location.
In Python for example, where package name and package location is distinct, I just need to tell the package manager the new location of the package. In the code that referencing the package I don't have to change anything as it still the same package name.
Go has been suffering this since the beginning and only recently came out with mechanism on how to handle this.
Browser Compatibility
Deno's API is built to follow the browser's API. This means that developers can easily go between the two. It's also a big gesture to align with the Web Standards. Rather than invent something different. Deno supports the web community by building on top of it
Decentralized Packages
Using URLs for packages also aligns with the web. URLs are what the web is built upon. So it makes sense to align with that also. Plus the GoLang community uses this method. So it's battle-tested.
Breaking Change From Node
Deno offers a similar development experience but with the opportunity to start fresh. The community has matured a lot since Node.js was created. All that experience can be brought into Deno to make better decisions for the future.
Mascot
Deno the Dinosaur is cute. That's +1 over Node.js ;)
Also, just to be clear. I love using Node.js. Just excited that Deno builds on what was amazing about Node.js and makes it even better.
One problem with using url for importing package is that it mix the concept of package location and package name (where it being referenced in the code). You'll start discover this problem when you want to change where the package come from (for example you have to fork some package into your own repo) but don't want to change the source code to refer to the new location.
In Python for example, where package name and package location is distinct, I just need to tell the package manager the new location of the package. In the code that referencing the package I don't have to change anything as it still the same package name.
Go has been suffering this since the beginning and only recently came out with mechanism on how to handle this.
This seem to be solved with import map but for now it still unstable feature.
deno.land/manual/linking_to_extern...