Today I'm going to be talking about this new runtime environment called Deno. But wait why should we care about Deno if we already have node.js. We should care, because Deno is actually created by the same person so you can almost say that Deno is node.js 2.0.
Ryan Dahl saw many flaws over the years that node.js had and basically said I could do this better. Ryan even had a talk called, "10 Things I regret about node.js" where he announced Deno.
Deno is also in charge of being its own package manager. So in node.js where we would require a package-management program like npm, Deno is able to be it's own package manager within single executable. Instead of having to install a library, all you would need is the Url of the file that has the instructions.
From the code snippet above that Deno website provides us, we can see that it's importing serve directly from the provided url. With this being implemented, it gets rid of the need for a package.json and also the huge nasty node_module folder that we have to do an extra step to ignore.
Deno also has almost all the browser Api like fetch built in. Where in node even though fetch is built in you can't use fetch in the server side unless you install a package. With Deno, if you are not writing Deno specific code you can write the same code you use for the browser, for outside of the browser. It allows for that flexibility.
One main focus about Deno is security. If a script needs access to the internet or access to the file system, you would have to grant that script permission to be ran. So in the case of a corrupt package that is trying to get access to another file to read or modify, you will get a warning in the console saying that the script will need permissions before it gets executed. Where as in node.js, it would just get ran and the damage will be done.