v0.1.2335 Sep 2026·Memory & reading

Real WebAssembly apps that share memory with the page now work

Almost every serious WebAssembly program - anything compiled from C, C++ or Rust - works by handing data back and forth through a block of shared memory: the page's JavaScript writes a string, an image or a struct into that memory, calls into WebAssembly to work on it, and reads the result back out of the same memory. Floati had been handing JavaScript a one-time COPY of that memory, so a write on the JavaScript side never reached the WebAssembly side and the single most common real-world pattern was quietly broken. Now the memory is genuinely shared - a write on either side is instantly visible to the other, through the same buffer, as in every other browser - and growing the memory correctly retires the old buffer for a fresh one. Together with the last two releases (running every valid module correctly, and rejecting every broken one), WebAssembly in Floati is now complete for real-world use: it decodes, validates, executes, and shares memory with the page without a copy. That takes the scorecard to 64.

Parity with the reference browser

74overall, as of v0.1.343

Web APIs / DOM surface42

Security architecture66

GPU / graphics acceleration68

DevTools / extensions72

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

What changed 3 changes

Memory & reading	The page and WebAssembly now share one memory. When a module exports its memory, the ArrayBuffer JavaScript sees is the module's actual memory, not a copy: a byte written from JavaScript is immediately readable by WebAssembly and vice-versa. This is exactly how emscripten and wasm-bindgen pass strings, buffers and objects across the boundary, so this is what makes real compiled-language apps work rather than silently read stale zeros.
Memory & reading	Growing memory behaves correctly. When a module grows its memory, the old buffer is retired (its length becomes zero, the way a real browser detaches it) and a fresh, larger one is handed out. The exported memory is now a genuine WebAssembly.Memory object with a working grow method, and repeated reads of its buffer return the same object until a grow, which is the identity check runtimes rely on to know when to refresh their views.
Memory & reading	No copies on the hot path. Because the buffer aliases the real memory instead of duplicating it, there is no longer a full copy of the heap made every time the page touches WebAssembly memory - important for the large heaps real applications allocate.