Status update - April 2023

Been working with gVisor, WASM, Next and more. Trying to do more one-day-projects in my free time, but they usually end up taking a week. So maybe next month I’ll try doing more one-hour projects, and I’ll end up with something that actually takes a day.

Static git repo site generator

Built a little static git repo site generator. You can read more about it here.

gVisor, runsc

I’ve been working on some projects that involve researching virtualization techniques. gVisor has been one of the main ones. It’s surprising that right off the bat I’m seeing better numbers when compared to containerd/QEMU when testing locally. A simple nodejs test gives me a really low cold-start time using runsc.

native:        0m0.275s
containerd:    0m1.856s (+1581ms overhead)
runc:          0m1.720s (+1445ms overhead)
runsc:         0m0.320s (+45ms overhead)

Actual overhead could be as high as low single-digit percentages according to some sources, but for a containerization tool where you’re already almost certainly running containers that cumulatively exceed the resources of the host and are priced accordingly? Not bad.

Interested in comparing it to firecracker soon.

Next / React stuff

Built a little site with NextJS recently and I can’t help but feel like it’s more complex than it needs to be. Or maybe I’m just not using the full features. I’m doing a plain static-export, so I’m not using anything that requires a server.

Next’s model of “we’ll optimize everything for you unless you use "use client"; or "use client";” is a bit too much. Whether you’ve got a website with a lot or a little interactivity, I think you can probably write a graph of all your components and draw circles around the ones that represent features, bundle those on their own, then bundle up your vendor dependencies as the single required library, then ship the site.

WebComponents sort of did this. Seems like it has come and gone without much fanfare, but there was something there. They got some things right – namely templates and components. React is here to stay, so there’s room to give a WebComponents-like pattern a try once more by using React as the rendering library, and maybe focusing on static vs. dynamic components.

Here’s roughly how I might build it:

• Templates directory for static React components, just build-time logic.
• Pages directory is also static React components, but they’re complete pages.
• Blocks directory is of dev-defined groups of dependencies.
• Features directory is for apps, big or small, that have simple entry points.

The big thing here is “blocks” – there’s no magic bundler here. The engineer has to think about what all the features need, and group these together. This is a challenge, and at some level some “human compiler” work, but it’s also just a sort of natural extension of grouping together the literal-features themselves. And maybe if the dependencies are too much to manage, that’s a sign of something the project needs to work on.

This could be the direction that Next is heading in anyways. But on the whole, it just seems like Next has a lot of magic, which is great when it works, but inevitably I need to debug magic, and I do not like to debug magic.

WASM

Also on the virtualization front I’ve been experimenting with WebAssembly and the recent growth around that. There are so many runtimes, tools, and services, it makes your head spin. At least one of them will win, hopefully a couple.

There are a lot of similarities between the push to write runtimes compatible with the ABI and projects like gVisor and Firecracker, which essentially implement almost all of the 200+ linux sys-calls.

There’s something here. I find myself saying that a lot about WASM, even while people criticize this intuition as something that’s not seen a killer WASM use-case. But I’m not sure there is one. Is it sandboxing JS? Could be. Is it allowing embedded smart contracts. Hard to tell. Is it Rust/C/Lua GPU monkey business running in the browser? Maybe. Is it running little VMs in a PaaS or serverless environment? At least in part, yeah. My bet is on it being used in a thousand small ways to run sandboxed, untrusted logic wherever – browser, cloud, desktop, and mobile.

Basically, WASM won’t have a React-moment, or replace Docker. It doesn’t need to in order to be useful in its own right.