v0.1.14814 Aug 2026·JavaScript & JIT, Memory & reading

WebAssembly numbers stay exact: 64-bit integers cross as BigInt

The final pieces of the WebAssembly interop arc. 64-bit integers now cross the JavaScript boundary as BigInt, exactly as the specification requires: an i64 result comes back as a BigInt that is exact past the 2^53 limit where plain numbers silently round (2 to the 60th arrives as precisely 1152921504606846976n), an i64 parameter requires a BigInt and throws a TypeError for a plain number - the same behavior as the reference JavaScript runtime and every browser - and an imported JavaScript function receives BigInts for i64 arguments and must return one for an i64 result. Alongside: WebAssembly.Memory.grow works before and after the memory binds to an instance (returning the old page count, the buffer tracking the new size), and a regression guard locks in that a module importing its function table and filling it from its own element segments dispatches call_indirect correctly - the standard emscripten shape. Every behavior verified against the reference runtime's WebAssembly as the independent reference. The Web APIs aspect holds at 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

JavaScript & JIT	i64 crosses as BigInt per the JS-API spec: results are exact past 2^53 where a Number would round, parameters require a BigInt (TypeError otherwise, matching the reference JavaScript runtime and every browser), and JS import functions see BigInt arguments for i64 parameters and must return a BigInt for an i64 result. Exactness caught by a test multiplying 2^40 by 2^20.
Memory & reading	WebAssembly.Memory.grow works on both sides of binding: before instantiation it resizes the page-held buffer; after, it grows the instance's live linear memory - returning the old page count either way, with the buffer's byteLength tracking.
JavaScript & JIT	A regression guard proves an imported function table filled by the module's own element segments dispatches call_indirect correctly (the dominant emscripten table shape), verified against the reference JavaScript runtime: even inputs route to one function, odd to another, byte-identical results.