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

Big objects are instant now, instead of getting slower the more you add

A deep speed fix to how our from-scratch engine stores an object's properties - the named fields a piece of data carries, like a person's name, age and email. The engine kept each object's fields in a simple list and, every time it looked one up or added a new one, walked the whole list from the top. That is fine for a small object, but for a big one - a data grid with thousands of rows, a large JSON response from a server, a lookup table built up in a loop - the cost grew with the SQUARE of its size: doubling the object made it roughly four times slower, so a big one could stall the page for seconds. The engine now keeps a smart index alongside the list (built automatically, and only once an object gets large enough to need it), so a lookup jumps straight to the field instead of scanning. Big objects go from slowing to a crawl to staying instant however large they grow - and small objects, the common case, are completely untouched and pay nothing for it. Nothing a page shows or does changes; it is the exact same result, faster. This clears the last big speed cliff left in the core of the engine, part of the run-up to making our own engine fast enough to render everything you browse.

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	Objects with many fields are now instant to read from and write to, however large they get. Before, every lookup scanned the whole object, so an object holding ten thousand fields was thousands of times slower to work with than one holding ten - and building one up in a loop could freeze the page for seconds. The cost is now flat no matter the size, the way it is in every other browser.
Memory & reading	The fix is a smart index the engine builds for an object only once it grows past a threshold - small objects (the overwhelming majority on a real page) keep the simple, cache-friendly list they always had and pay nothing extra, not a byte of memory nor a cycle of time. This mattered because that list is the single most-used structure in the whole engine, touched on nearly every line of script a page runs, so the fix had to make big objects fast WITHOUT slowing the small ones down at all - and, measured, it does.
Memory & reading	Everything an object does is byte-for-byte identical to before - the order fields come back in, which field wins when a name is set twice, how missing fields read - only the speed changed. That equivalence is proven by running large randomised sequences of object operations through both the new fast path and the old simple one and checking they never disagree, plus a safety switch that reverts to the old behaviour on the exact same program if it were ever needed.