Built with Deno
If you view my page source you might see:
<meta name="generator" content="deno 1.8 | svelte 3.35.0">
That meta tag is a little spice I’ve mixed into my personal static site generator. It’s nothing complicated. Just a few build scripts to server-side render Svelte templates with data from markdown files. I had written it in Node. Now I’ve translated it into Deno.
Deno: First Impressions
Truthfully this isn’t my first time with Deno but it’s my first project of any real significance. The Deno Manual has a good introduction so I won’t bore you. Below are my initial thoughts after using Deno “in production”.
Deno is good. Deno feels modern.
Compared to Node the Deno API and standard library are easier to work with. That should be a given because they were designed with years of hindsight. Everything is async and promise-based. Node is keeping up but it can only go so far without breaking APIs.
There is no NPM equivalent for Deno. There doesn’t need to be. Deno uses ES modules and URL imports. Modules can be versioned in the URL. Optional import maps allow for tidier name resolution. Modules are cached globally (no
node_modules). All good stuff.
require code. The same pain found writing modern Node with ES modules. CDNs like ESM and Skypack attempt to automate compatibility but they’re not perfect.
Deno includes built in support for code formatting, linting, testing, bundling, and more. It does seem like a lot for the Deno project to maintain. Will core functionality suffer? What about bloat? Take this recent documentation commit:
- the ~15 megabyte zipped executable + the ~25 megabyte zipped executable
It refers to how Deno “is runnable with nothing more than [ … bytes]” – how often will that line be rewritten? It would be nice to have a slim Deno build without the extras. I’m running a Deno web server on a Raspberry Pi that only needs
That said, I’m all for reducing dependencies. Having the full suite of tools in Deno could keep development simple.
Security permissions are a valuable feature. Although I can see myself defaulting to:
deno run --allow-all --unstable
Whilst developing, for lazy convenience. That’s a me problem I guess.
Deno is very intriguing. I will maintain my own website built with Deno for the foreseeable future so I can keep watch. It’s too early to adopt for client projects.
The big question is does Deno improve upon Node enough to justify the change? From my limited experience I see many improvements and big potential. Deno may prove to be better in the long run, but better isn’t a guarantee to replace “good enough” – and Node is plenty good enough.
I can imagine a tipping point where compatibility is such that
deno becomes a drop-in replacement for
node. Until then I don’t see Deno usurping Node. Even then, it’s difficult to justify replacing the incumbent. There are many reasons not too.
Early last year I wrote my first impressions on Netlify. Ever since then I’ve used Netlify to host my projects. Netlify builds using a Docker image with Node and other tools installed. Sadly the build environment does not include Deno yet.
I could just build locally and upload static files. However, pushing source to Github with continuous deployment makes me feel like a professional. As it turns out I can just download and run any old binary.
# netlify.toml [build] publish = "./public" command = "./src/deno/netlify.sh"
#!/bin/bash curl -fsSL https://deno.land/x/install/install.sh | sh /opt/buildhome/.deno/bin/deno --version
This adds an extra minute to the build. Not ideal but I do get plenty of free build minutes with Netlify. I could add the binary to my Git repo — I think Netlify does some caching between builds. That wouldn’t be nice to maintain (not to mention it’s 75MB (unzipped)).
Anyway, if you use Node keep an eye on Deno. It has momentum.