Deno is the future

June 2, 2020

I absolutely love Node.js, however it does irritate me from time to time. The ecosystem is cluttered and requires you to write Javascript in a way that seems counter-intuitive to those who code for the browser. Thankfully, our lord and saviour Ryan Dahl has brought us Deno, a fresh take on a backend JavaScript runtime.

Node is very powerful, but with great power comes great responsibility. Node automagically has access to your network, as well as read and write access to your disk. Depending on the use case, this might very well be ok but it is concerning to know that any Node application I could run will have these permissions by default. Deno on the other hand is secure by default. Need network access? Pass the --allow-net flag. Need disk read/write? Pass the --allow-read and --allow-write flags. This approach puts the power in the hands of the one running the code. ANy permission that is needed but not allowed will produce an error and halt the entire application. What definitely helps too is how clean and useful these messages are.

I'm sure mentions of Node bring with it awful memories of... node_modules. As part of the ecosystem, Node has a node_modules directory that weighs more than the moon and is managed by the npm package manager (or yarn for those who don't hate themselves). The Node ecosystem relies on this centralized repository for packages. With Deno, packages follow the ESM standard and can be imported by referencing a URL. The best part about this is the first time the application is run the libraries are cached locally and are only re-downloaded if it changed. For Deno, I would suggest a CDN like

Deno has reached v1.0.0 but the team are constantly pushing new changes to it and improving the ecosystem. If you would like to experiment or even contribute, now is the best time to do so. Now to figure out how to run Deno in a firebase cloud function...