v0.1.2112 Sep 2026·JavaScript & JIT, Memory & reading

A correctness fix for today's list-speed improvement

The speed-up that shipped earlier today made reading and updating the fields of an item taken from a list much faster. It had one narrow flaw: when the item was declared the older way (with `var`, which unlike the modern `let` and `const` keeps existing after the loop that used it) and then read again after that loop, the fast path could hand back a value that was a step out of date. This release fixes that. The fast path now engages only for the modern, block-scoped forms (`let`, `const`, and destructuring), where the item cannot be read after the loop and the optimisation is provably safe, and it leaves the older `var` form on the reliable path that was always correct. The speed-up is unchanged for the common cases that make up almost all real code; this only closes the one case where fast and correct had briefly parted ways. Correctness before speed, always: a faster wrong answer is not worth shipping.

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	Fixed a case where the new list-item speed-up could return a slightly out-of-date value: an item declared with the older `var` keyword and then read again after the loop that used it. The fast path now stays out of that case and lets the reliable path handle it, so the value read after the loop is always exactly right.
JavaScript & JIT	The speed-up itself is unchanged for the common way modern code is written - items declared with `let` or `const`, and destructuring - which is provably safe because those items go out of scope when the loop ends and can never be read afterward. Those cases keep the full 2.5 to 3.5 times improvement.
Memory & reading	This is the discipline the whole engine is built on: every optimisation must give byte-for-byte the same answer as the plain, slow path, checked automatically. When one narrow case slipped through, the rule was to pull the fast path back to exactly where it is proven safe rather than leave a faster-but-wrong result in place - and to add a standing test so it cannot recur.