Feb. 21, 2023, 8:41 a.m.

Browsertech Digest: Rust on the web, pixel streaming

Browsertech Digest

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:

  • JavaScript has become an accidental bytecode for the web: the JavaScript that runs in the browser is usually produced by a compiler and indecipherable by a human.

Screenshot of indecipherable compiled JavaScript code

  • Because JavaScript was created to be a programming language, not a compile target, there are a bunch of inefficiencies and accidental complexity that come from using it as one.
  • WebAssembly is the result of intentionally designing a compile target for the web.
  • Rust is a good WebAssembly language because few other languages have a modern developer experience and also are not garbage collected.
  • Rust/Wasm might is probably not more performant for typical happy-path React-style applications that browsers have invested heavily in optimizing for.

The advantage of Rust+Wasm is not that you can sprinkle it on an app to get better performance, but that you can have a clear mental model of the performance characteristics of your code. You can know definitively how data will be laid out in memory, or how many memory allocations a block of code will make.

  • JavaScript isn’t going anywhere, but Rust+Wasm will make more complex and compute-intensive applications tractable.

Pixel-streaming data visualization

Back in November, I write in the digest about the rise of pixel-streamed UI.

We just released a demo of MagicCanvas, tech we're building that can seamlessly switch between local GPU and remote GPU rendering within the browser.

Still of a demo video showing a remotely-rendered LiDAR point cloud of Manhattan, with text that reads "remote rendering / 189.9M points / 1.4GB"

The reason for doing this are that if you try to send a multi-GB dataset down to the client, the initial transfer will be slow and the browser (or client-side GPU) might not be able to handle it.

Using a remote GPU lets you run the rendering near a cache of the data for faster load time. It also lets you run it consistently on the same hardware.

Switching between local and remote leaves the option of using local rendering for small-scale datasets, and remote rendering for large datasets, while using the same rendering codebase.

Until next time,

-- Paul

You just read issue #15 of Browsertech Digest. You can also browse the full archives of this newsletter.

GitHub X YouTube LinkedIn