All in on Deno

written May 6, 2023

Deno is a server-side JavaScript runtime by the creator of Node.js, Ryan Dahl. Its first rumblings were heard in 2018 with Ryan's famous talk 10 Things I Regret About Node.js where he layed out a compelling rationale for ripping Node down to its studs. In 2020, after a lengthy rewrite from Go to Rust, Deno 1.0 was released featuring the following example.

import { serve } from "https://deno.land/std/http/server.ts"; for await (const req of serve({ port: 8000 })) { req.respond({ body: "Hello World\n" }); }

To a rare breed of Skypack aficionado, these three mostly-terse lines of code might have looked everyday, but to anyone else who bothered to pay attention this was alien script.

ESM imports, from URLs, of TypeScript files no less
Top-level await
Async iterators replacing callback hell with clean for-loops

It also had a batteries-included binary (linting, formatting, testing, etc.) and a secure-by-default sandbox which, strangely, seemed to have the most buzz, overshadowing the rest which was much more impressive and avant-garde.

Mired in the pandemic, I lost sight of Deno until April 2022 when I spent a day reading the release notes and falling in love with its philosophy and design. I decided to take the plunge.

Its vastly superior developer experience was immediately apparent. After about a month of after-hours tinkering, I have since then never written a line of Node.js outside of work. It's been over a year and I'm here to stay.

Top Feature

I knew that Deno being batteries-included would be a significant boon, as would native TypeScript execution. What I did not foresee was the deep significance of its ability to import and execute TypeScript from URLs. It radically reorients the way you write and organize software. The CLI behaves the same way. Here's an example from the docs:

deno run https://deno.land/std/examples/welcome.ts

Death to bundlers. Death to package managers. Every uncompiled TS file is a library unto itself. Users can import the exact code they want and nothing more (tree-shaking permitting) and do not need to pull down an entire package to run one portion of it. No more node_modules singularity. Every project is mostly a monorepo, for free, with no wiring of script runners. And if I want to see what's in a file, I can CMD + click on its URL and read it in full, un-minified, complete with comments and context - no sourcemap required.

Best-Kept Secrets

There is a lot of information in the wild about Deno's headline features. I don't need to add to the pile. Instead here is a plump list of notable things I love about Deno which no one ever talks about:

Deno supports JSX and TSX out of the box.
The official style guide is a must-read for any library author or language designer.
Typical Deno projects are sparse and flat, increasing signal-to-noise ratio and making them easier to reason about, thanks to these features:
- All the included tooling (linter, formatter, test runner, ...) is zero-config with smart defaults.
- When you do need to configure something, it's all in one deno.json file.
- Dependencies are downloaded to an ambient cache. This means no node_modules or similar.
Wherever plausible, Deno uses existing web standards, even in unlikely places. For example:
- Deno's localStorage API caches data in a temp file that persists between executions.
- Deno implements alert, prompt, and confirm... in the command line.
- Deno's implementation of fetch can also retrieve local files.

Coming Soon

Deno is rearing up for its 2.0 release imminently and they've put out some exciting features lately, most notably their built-in key value store – an ergonomic wrapper around SQLite which also works in their cloud offering, Deno Deploy.

I'll have much more to say about Deno in the near future. I'm still writing in it every day! My current jam is plopping utilities and reusable scripts into my project handy, a sort of second standard library I will develop over time. Some of the developments deserve blog posts of their own.

👋