One especially unique feature of Deno is its security model. By default, Deno scripts aren’t allowed any dangerous access: not the file system, not the network, not environment variables, not even high-resolution timers. Basically, they need to be hermetically sealed scripts, or be explicitly granted permissions by the user to do anything. The upshot is that you can blindly run a script (e.g. the official welcome script, via
deno run https://deno.land/std/examples/welcome.ts) safe in the knowledge you can’t hose your computer.
For awhile, I’d had an idea that I’d port some of my personal programs such that I could simply
deno run them right off my GitHub account, rather than installing them. In practice, that proved a bit tricky: Deno’s APIs for reading local files (e.g.
Deno.readFileSync) were different from reading remote files (via
fetch), so handling a script running both locally and remotely, if it required external resources, ended up being a bit of a pain and require varying amounts of conditional branching. Not a deal-breaker in a strict sense, but it took enough fun away I didn’t bother.
But I was happy to discover that Deno 1.16 actually added
file:// URL support to
fetch. That means that
fetch(new URL("./file.txt", import.meta.url)) will work both when run locally and when run remotely. I gave this a shot in the silliest way imaginable, and, well…feel free to enjoy my Deno port of fortune, Dortune. Sure, you can clone and run it locally, but you can also do
deno run --allow-net https://git.sr.ht/~bmp/dortune/blob/main/dortune.ts and enjoy the exact same code working remotely without installing anything.
Granted, this particular example is fairly ridiculous, but I’m honestly quite excited about having a suite of personal utilities I can keep up-to-date transparently and that don’t care where they run.