v0.1.14714 Aug 2026·Rendering, Memory & reading

WebAssembly interop rounds out: imported globals and memory

Following 0.1.146's JS-import callbacks, the other two legs of how a real wasm module talks to its page now work. Imported globals were being skipped by the decoder, which silently misaligned every global index the module's own globals used - they are now modeled at the front of the index space and receive the page-supplied value, whether passed as a plain number or a WebAssembly.Global. Imported memory goes further: the page can construct a WebAssembly.Memory, pre-seed bytes into it, and hand it to the module - the module reads the seeded bytes, and after it writes, the page reads the results back through the same memory object's buffer, live. The WebAssembly.Memory and WebAssembly.Global constructors exist now, so pages that build their import objects the standard way no longer fall at the first line. Every case verified against the reference runtime's WebAssembly as the independent reference. Web APIs moves 63 to 64; the overall holds at 57.

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

Rendering	Imported globals occupy the front of the global index space, as the specification requires - the decoder used to skip them, so a module that imported a global and used its own read the wrong slots. The page-supplied value binds after instantiation, coerced to the declared type; both a plain number and a WebAssembly.Global-shaped value work.
Memory & reading	Imported memory: a page-constructed WebAssembly.Memory hands its bytes to the module at bind time (the module's own data segments still apply on top, as its contract with the memory requires), and after binding, the memory object's buffer reads the instance's LIVE memory - so JavaScript sees what the module wrote, the round trip every wasm-accelerated page depends on.
Memory & reading	Verified against the reference JavaScript runtime end to end: a module that stores and loads through imported memory sees a pre-seeded byte (55), and after poke(16, 123) both the module's own load and the page's view of the buffer read 123 - byte-identical to the reference runtime's behavior. Honest limits: memory.grow is not supported yet and says so; imported tables remain unmodeled; the start section runs before imports bind.