v0.1.6331 Jul 2026·Rendering, JavaScript & JIT, Memory & reading

Four real sites stopped breaking, and the engine learned to explain itself

This release is about JavaScript correctness on the real web, and it started by teaching the engine to say where an error happened. Errors now carry a stack trace - the chain of functions that led to the failure - which is both something pages expect (every error-reporting tool reads it) and the thing that made the rest of this release possible: before it, a failure on a minified site named a single letter and nothing else. With that in hand, four sites that had been failing were traced to real bugs and fixed. the encyclopedia's language picker died because a variable declared inside a loop was being created in the surrounding code as well, quietly replacing an unrelated variable of the same name - which is a collision that happens constantly, because minifiers reuse short names everywhere. Svelte's site died because a script could not find its own tag on the page. A news site died because one of the building blocks a popular compatibility library checks for at startup was the wrong shape, so the library concluded the browser was broken and wired itself up incorrectly. And a testing service died because taking apart an array with the shorthand syntax only worked on real arrays, not on the other things the language allows there. Alongside those: replacing a built-in page function with your own now works, which is how analytics, error reporters and polyfills all attach themselves; several older corners of the language that had silently done nothing now work, including setting an object's prototype directly and calling a parent method from a plain object; and asynchronous loops no longer silently produce nothing. On the rendering side, a table cell spanning several rows no longer pushes the columns beside it to the wrong widths, text sits a fraction closer to where the reference browser puts it, and pages with no character outside the Latin alphabet now skip loading a 22MB font they never draw from, which halves the time spent on fonts for a typical page.

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 4 changes

Rendering	Errors now carry a stack trace, the chain of functions that led to a failure. Pages expect it (every error reporter reads it), and it made the rest of this release findable: before it, a failure on a minified site named a single letter and nothing else.
Memory & reading	Fixed four real sites: the encyclopedia's language picker (a variable declared inside a loop was leaking into the surrounding code and overwriting an unrelated one of the same name), Svelte (a script could not find its own tag), a news site (a compatibility library saw a built-in of the wrong shape and decided the browser was broken), and a testing service (array destructuring only worked on real arrays).
JavaScript & JIT	Replacing a built-in page function with your own now works, which is how analytics, error reporters and polyfills attach themselves. Several older corners of the language that had silently done nothing now work, and asynchronous loops no longer produce nothing.
Rendering	Rendering: a table cell spanning several rows no longer pushes the columns beside it to the wrong widths, text sits closer to where the reference browser puts it, and a page with no non-Latin characters skips loading a 22MB font it never draws from, halving font time for a typical page.