Welcome to issue #14 of the digest.
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:
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.
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.
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