There is an ongoing tug-of-war over the future of server-side WebAssembly.

One side embraces the idea that Wasm was designed in the context of a broader web platform. Their approach to running Wasm outside of the browser is to transplant relevant parts of the web platform onto the server, and run Wasm within this browser-like context.

The other side sees Wasm as a CPU-independent bytecode, for which the browser is just one use case. Their approach is to standardize a syscall-like interface (WASI), akin to the one an operating system provides to native code.

The source of the rift is that Wasm doesn’t specify a particular interface with the outside world, by design. While Wasm itself is portable across platforms, it’s only really useful when paired with such an interface.

Welcome to issue #15 of the Browsertech Digest.

In a few months, WebGPU will be enabled by default in Chrome. This issue is about why that matters for games and machine learning.

Background: GPU compute on the web

To do any sort of high-performance graphics, you need to be able to send instructions directly to the computer’s graphics processing unit (GPU).

Welcome to issue #14 of the digest.

The Bull Case for Rust on the Web

Over on the Drifting blog, I wrote about why we increasingly see Rust pop up in the stack of in browser-based apps.

A tl;dr:

Welcome to issue #13 of the browsertech digest.

WebContainers

Most browser-based IDEs work by running the development toolchain — compilers, packaging tools, etc., on a VM in the cloud. One exception to this is StackBlitz, which instead compiles a version of node.js into WebAssembly and runs the entire development toolchain client-side.

This week, StackBlitz launched WebContainers, which exposes their browser-based node.js runtime for others to build on. Although the runtime itself runs entirely in the browser, it is designed to be used in conjunction with a remote network proxy, which they provide (presumably needed fetch packages from npm, among other things).

Welcome to issue #12 of the Browsertech Digest. Today’s issue is about the trend of applications rendering their entire UI directly on the GPU.

The Good Old Days, When Apps were Apps

Traditionally, if you wanted to write desktop software, you would use the operating system’s APIs to create a user interface. That’s why Windows apps looked like Windows apps, and Mac apps looked like Mac apps.

This also meant that if you wanted to turn a Windows app into a Mac app, it was an expensive and time-consuming process. As browser rendering engines became more powerful, developers realized they could be used as a foundation for a cross-platform UI framework, bypassing much (not all) of the work in maintaining a cross-platform app.

Hey folks, this is issue #11 of the digest.

Browsertech SF

This past week we ran our first Browsertech meetup outside of NYC, in San Francisco. I’m really happy with how things came together.

Hey folks, welcome to the tenth issue of Browsertech Digest.

Apps are distributed systems now

Something that’s been fascinating me lately is how distributed systems theory has quietly snuck into the application layer of software.

Web apps have long been built on top of a distributed data layer — a replicated RDBMS, say, or a web-scale document store. But the complexity was handled by database engineers, not application engineers. Client-side code could reason about “the server” as an abstract, singular entity, blissfully unconcerned by its distributed nature.

Welcome to issue nine of the digest. Browsertech SF is one week away. If you’re in San Francisco, come say hi!

Apropos of Apple’s addition of two new chips to their M2 line, this issue is about how Apple silicon is breaking developer workflows, and why it could be a catalyst for server-side WebAssembly.

The golden age of universal containers is over

In the nine years since Docker was first released, container images have become the default way to package software for deployment on servers.

Hey folks, happy new year and welcome to the eighth issue of Browsertech Digest.

Browsertech SF

This month, we’ll be hosting our first browsertech event outside of NYC. I’m very excited to have talks from Gabriela at Womp and Hamilton at Rill Data. Myself and the Drifting team will have a few things to demo as well.

Registrations are now open. Here’s the event page.

Welcome to the Browsertech Digest, this is issue #7.

Browsertech NYC II

Last week we had the pleasure of hosting Yining Shi at our second in-person browsertech event in NYC.

Yining is a founding engineer at Runway, one of the original AI-based creativity tools founded back in 2018. Runway is also known for collaborating with Stability AI to develop Stable Diffusion. Yining also teaches about creative ML at NYU.

Hey folks, this is issue #6 of the Browsertech Digest.

Welcome to the new subscribers who found it through our CRDT post.

You might not need a CRDT

Over on the Drifting blog, I published a post called “You might not need a CRDT”.

Hey folks! This is issue #5 of the browsertech digest.

The Browsertech Index

Between operating Drifting in Space, running Browsertech events, and writing this newsletter, I have a lot of exposure to people building ambitious apps that run in the browser.

In the early days, I kept a mental list of products to keep track of, but it quickly outgrew my brain and I had to start making notes.

Welcome back to the Browsertech Digest. This is issue #4.

Mighty

Yesterday, Mighty founder Suhail Doshi announced a pivot from building a “Chrome in the cloud” browser and into building an AI-powered Adobe Creative Suite competitor.

Mighty started in 2019, and represents the vanguard of what I think of as the neobrowsers: upstart web browsers that treat the browser not as a tool of passive consumption, but instead embrace the browser’s role as an operating system of sorts for modern apps.

Welcome to another Browsertech Digest! This is issue #3.

Womp

Last week, the browser-based 3D editor Womp launched.

Womp is notable for a couple of reasons.

SQLite gets wasm support

SQLite announced official support for wasm. Specifically, support for browser targets via emscripten. The goal is to support persisting data client-side via the Origin Private File System browser API, which isn’t ready yet.

For context, SQLite is a public-domain database that’s become the go-to embedded database across lots of software (we use it in Plane).

Previously, browsers attempted to standardize a built-in SQLite API via the Web SQL Database standard, but it failed to become a standard and browser support is currently mixed.

For this inaugural issue of Browsertech Digest, I want to talk about what we mean by browsertech, and why it matters.

Web browsers have grown in scope from humble hypertext renders to a runtime for full-fledged applications (see: Google Maps; Figma).

Along with this evolution, the term “web application” has expanded in scope to include not just webmail clients and social media sites, but anything that happens to run in the browser, from video editors to 3D games.

When we talk about browsertech, we’re talking about that latter emerging subset of web development, which consists of writing desktop-like applications on top of browser APIs like WebAssembly, WebGPU, and WebRTC.