You mentioned compressing the FastAPI payloads by 90% to keep the browser from melting. I'm really curious about your approach there did you just crank up gzip/brotli on the JSON responses, or did you have to switch to something like MessagePack, Protobuf, or a custom binary format to handle that volume of moving GeoJSON features?
Also, never apologize for the "movie hacker" UI. A project like this absolutely deserves that aesthetic. Awesome work!
The 45% overhead reduction in the Dodrio experiment by skipping the JS glue is massive. But I'm curious about the memory management implications of the WebAssembly Component Model when interacting directly with Web APIs like the DOM.
If a Wasm Component bypasses JS entirely to manipulate the DOM, how does the garbage collection boundary work? Does the Component Model rely on the recently added Wasm GC proposal to keep DOM references alive, or does it still implicitly trigger the JS engine's garbage collector under the hood?
Really excited to see this standardize so we can finally treat Wasm as a true first-class citizen.