Deno Primer & Isolate Clouds
By Alex Mackenzie at
"node_modules, the heaviest object in the universe"
Should you wish to stay updated on future posts, subscribe to receive carrier pigeons at my substack.
The theoretical physicist, Wolfgang Pauli, is widely attributed for the counter-intuitive critique: “it’s not even wrong”.
By this, Pauli means that ideas devoid of strong opinions are categorically worse than those ideas that are deemed to be incorrect, or perhaps even offensive, by some.
I’ve found this same sentiment to be true for developer tools — which I’m sure is exactly what Pauli was indirectly referring to.
The “Developer Community” is known for being particularly opinionated. Make an explicit product decision and you will be simultaneously worshipped and chastised for it. This was perhaps most evident in Python’s addition of the Walrus Operator, whose reception led to the benevolent dictator for life himself stepping down. Team Guido over here!
Arguably one of the most opinionated — particularly due to its lineage — developer tools of late is a runtime called Deno. This emerging runtime is important not only because I built this very blog on top of it, but also because it (along with Cloudflare Workers) represents a new paradigm in cloud computing. Deno [Deploy] is an “Isolate Cloud”.
If the Isolate Cloud really is akin to its predecessors, virtual machines & containers, ~VMware & ~Docker, then it’s likely worth paying some attention to. Let’s see what the cloud v3.0.0 is all about.
There’s a medley of terms and foundational technologies here that we’re going to need to unpack. But first, one explanation and then some history.
A “runtime” is a piece of software that helps developers create, compile and execute programs. To grossly oversimplify, execute = make a program do what it’s supposed to do.
To execute this program I would open up my terminal, type “deno run grossly.js”, et voilà, my program will compile, execute and then return 2 (quick mafs)
Utilizing V8 vs. JVM
Enter our protagonist, Ryan Dahl.
During JSConf 2009, Dahl shared a new server-side runtime called Node.js. It touted itself as a “purely evented, non-blocking infrastructure to script highly concurrent programs”.
Technical Detail: “Non-blocking” means that whilst some code - perhaps a database query - is waiting for a response (ie still being executed), subsequent code is executed in the meantime. Thus, your program is “concurrent” because it’s executing multiple lines of code at once!
Fast-forward to 2022 — I promised this would be brief! — and Node.js is ubiquitous. As a consumer, you likely used a web application built on top of Node.js today (a la Uber). With 11m+ developers using Node.js & its concurrent comrades, it’s hard to miss.
However, on May 13, 2018 Node.js saw some developer churn in the shape of our protagonist, Ryan Dahl, who had a new PowerPoint and new idea.
** A new runtime has entered the groupchat **
Yes, the creator of the Node.js runtime is now building its ~adversary, Deno. This is about as Hollywood as developer tools get & I’m here for it. Let’s pick back up our definition, now armed with some history and new domain knowledge.
Unlike my publishing cadence, I’m going to stay consistent here and keep tackling the foundational technologies before we delve into the simple, modern, and secure characteristics of Deno. Next candidate, TypeScript.
In programming languages, “types” are a set of categories that describe what a value in a program is (ie is it a number, a string, a boolean etc.), and as a result, what operations can be taken on the value.
For example, it doesn’t make sense to multiply (an operation!) two values that are strings (e.g., “subscribe” * “to-my-newsletter”), but multiplying numbers does.
Let’s see what happens when we try to perform a multiplication operation on strings.
That’s a lotta “red” + “technical jargon”. What’s happening here is we’re running into what’s known as a TypeError. Our code isn’t being successfully executed, as string types can’t be multiplied by one another.
Whereas in TypeScript, variables lack imagination. A variable needs to be told that it should be a string. Par example:
Why go through the additional effort? Usability. Being explicit about what your code should consist of, and hence, do, ensures it’s used by you, and others, as intended.
Back to Deno.
Deno supports TypeScript “out of the box” (ie it just works). Whereas if you want to execute TypeScript with Node.js you have to install a specific software library & do a little more grease work.
** TypeScript **
Ah, WebAssembly, Wasm, the ordained cool kid on the proverbial block. As I very briefly helped lay out in Luke Byrne’s canonical post, Wasm is a compilation target. What this means is, that a higher-level language (e.g., Go) gets compiled (ie turned into) a format that more closely resembles “machine code”.
** Wasm savants lay down your weapons I'm not finished **
Naturally, for a technology to receive this much fanfare, there’s much more to it. However, this is a rabbit hole for another day. What’s important to know is that Deno exposes utilities (e.g., a WebAssembly class) that developers can use to execute WebAssembly code.
To Node.js’ credit, their support for Wasm seems pretty good too.
** WebAssembly (kinda)(you’ll thank me) **
Astute readers — yes, this engine handles the “compilation” and “execution” part of our initial runtime definition.
Execution is due a little more time. Sure, you now have 1s and 0s that your computer understands, but your computer requires some additional help to ensure these 1s and 0s are understood and dealt with (ie executed) in the best way possible.
Let’s unpack execution a little further.
** Notably simplistic analogy inbound **
Imagine opening whatever book you’re currently reading on its current page.
You’ll likely read the text on the page in some order (remember, “call stack”), know who the characters mentioned are based on prior pages (remember, “memory heap”) and perhaps change your view on how the plot will pan out (remember, “garbage collection”).
V8 uses a “call stack” to prioritize what lines of code are executed when, a “memory heap” to store information that can be used subsequently, and a “garbage collector” to delete information that’s no longer relevant/useful.
We’ll return to V8 when we delve into the “Isolate Cloud”.
** V8 ..fait accompli.. **
If you’ve frequented the vestibules of the WebAssembly FC (football reference not a technical acronym) then there’s no doubt you’ve stumbled into the compilation target’s comrade, Rust.
Rust, per Stack Overflow, has been the most popular programming language for 6 years straight. So, we’ll linger a little here.
Systems languages (C, C++, Go, Rust, etc.) are generally used to write programs / utilities that will be used by developers to interact with some underlying piece of hardware (think a CPU).
For example, V8 itself is written in C++, the Mac operating system is primarily composed of C code, the Python language is written in C (ooh, meta), and the Deno runtime is.. “built in Rust”.
The big difference vs. languages such C++ (aside from its preferential ergonomics!) is that Rust is “memory safe”.
Technical Detail: “memory safe” means that information your programs store (e.g., a name in an array) can’t be improperly accessed or changed. Your stored information (ie memory) is.. safe. With C++ this isn’t the case.
To put the importance of memory safety into perspective: in 2019 Microsoft estimated that 70% (!) of all security vulnerabilities in their products over the last decade have been due to memory safety issues.
As it relates to Deno, Rust is a modern language used to build system-level utilities (such as a runtime!) due to its memory safety et al. It’s the best tool for the job — you don’t need to know anything else.
** Rust has been electrolysis’d!! ha **
I salute you if you’ve made it this far. Now that we’ve laid the technical foundations, let’s dig into our rather opinionated runtime, Deno.
What makes Deno “simple” is a subjective matter. I would sum up its simplicity as a collection of characteristics:
Web Compatability: Deno comes packaged with existing “web standards” — ie the same APIs that the browser exposes to frontend developers. Whereas Node.js doesn’t.
“Batteries Included”: Deno comes bundled with a number of useful utilities. Want to build a web app? Use their web framework, Fresh. Want to format your Fresh code? Use deno fmt. Want to deploy said web app? Use Deno Deploy. Want me to stop? … fair.
Dependency Management: Deno imports dependencies (ie other people’s code you’re using) via a URL import vs. a “package registry” like npm. No more node modules / package.json / the “require()” syntax 🥲 (those who know, know).
** simplicity + web standards + batteries included in one fell swoop **
“Modern” is easy. As mentioned already, Deno is unshackled by the technical inertia of Node.js — the runtime uses/supports new kid on the block technologies: Rust, TypeScript, and WebAssembly.
** modern **
“Secure” is deserving of a little more attention. I suspect Pauli would speculate that this is where Deno could.. be wrong.
Deno is secure by default. The runtime requires you to explicitly state what a program’s allowed to do/access.
For an example of the above example:
deno run --allow-net fetch.ts
tells Deno to compile and execute the file “fetch.ts” and allows (--allow) the file to access the computer’s network (-net).
** *secure --is scratched off the list.ts!* **
Scratching those definitions felt good. You did it, you know what Deno is + a host of some of the most important technologies of the modern web.
However, those of you with no garbage collection (..good memory..)(..I’m sorry..) may remember at the beginning of this primer I mentioned that Deno Deploy is an “Isolate Cloud”.
In Cloud Computing Without Containers, Zack Bloom of Cloudflare fame explains that Cloudflare “Workers” (their Serverless product) don’t rely on virtual machines or containers. At the time this was unique vs. serverless competitors such as AWS Lambda. This was kinda a cloud infra equivalent of the proverbial mic drop.
Technical Detail: “Serverless” doesn’t actually mean no-servers. It’s really a business model. With serverless, developers don’t have to rent a specified amount of backend services (ie servers) from their cloud provider. Instead, they dynamically (ie automatically) rent based on their usage.
Instead, Cloudflare Workers rely on a little something called V8 (!!) Isolates — a particular ~feature of Chrome’s V8 engine. It’s this same technology that Deno Deploy uses to make application deployment an absolute breeze. It nearly feels.. wrong.
Isolates allow disparate cloud computing users (ie “tenants”) to not only share an operating system (this is what containers enable), but to inherit the same runtime environment (yes, e.g., Deno!) too.
Why does this matter?..
Well, firstly, developers get to think about the cloud infrastructure their code runs on even less than when they use containers. With isolates, ~all they have to think about is writing their application code.
For context, managing infrastructure is analogous to “admin”, y’don’t want to do it, you just want to play rugby outside (write code).
Secondly, isolates are incredibly “lightweight”, meaning they take up very little "space” on a given server. Why? Again, because isolates solely contain application code vs. a bunch of other contexts needed when deploying to containers.
More space unlocks some rather interesting features for the users of isolate clouds. In Deno Deploy’s case, every time you deploy some code, Deno Deploy provides an entirely new server to host that code. Then, when you commit some changes to your code and deploy those changes, Deno will persist the old code on the original server and “spin up” a new server to host your updated code.
This makes “rolling back” to previous versions of your application (as well as testing) a walk in the park.
In Cloudflare’s case, more space™ means that it’s economical (among other things) for them to make copies of your application code and deploy these copies across their global mesh of servers. As a result, you have a truly global, low latency, application.
! How cool !
So yeah, when someone’s inevitably bloviating about the “future of cloud” think (but never say out loud) “more space” and you’ll likely be able to wade through the technical jargon and land on the same endpoint. Nice work!
** isolate cloud fin **
Enjoyed reading / have thoughts? Feel free to reach out 👋🏻