Deno is a Browser for Code

I haven’t really played with Deno yet, but conceptually I love a number of its founding premises:

In order to publish a website, we don’t login to a central Google server, and upload our website to the registry. Then if someone wants to view our website, they use a command line tool, which adds an entry to our browser.json file on our local machine and goes and fetches the whole website, plus any other websites that the one website links to to our local websites directory before we then fire up our browser to actually look at the website. That would be insane, right? So why accept that model for running code?

The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. You, the person invoking the code, get to tell that code what it can and can’t do, externally. Also, like a browser, code can ask you permission to do things, which you can choose to grant or deny.

With Deno, there is no package manager. You only need HTTP.

The HTTP protocol provides everything that is needed to provide information about the code, and Deno tries to fully leverage that protocol, without having to create a new protocol.

Also this bit:

This leads us to the Deno model, which I like to call Deps-in-JS, since all the cool kids are doing *-in-JS things.

This is a really interesting conceptual look at what Deno is doing and how it’s different. I like it. It feels very “webby”.