v0.1.3301 Oct 2026·Rendering, JavaScript & JIT, Memory & reading

JavaScript scores 100, and big pages stop stuttering when they clean up

Floati's JavaScript engine now scores 100 out of 100 on every workload we measure against the reference browser's own engine, and every change is now also checked on real websites: a speed-up only counts if no real page gets slower. When a page throws away a large structure, freeing it no longer freezes the page, because a helper thread does most of the work. Small functions that read a module's settings, destructuring in loops and object spread got many times faster, and three long-standing JavaScript bugs were found and fixed on the way.

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

JavaScript & JIT	Every measured workload at full marks. We time 43 everyday JavaScript workloads in Floati and in the reference browser's engine on the same machine, and Floati now earns the full score on all of them, with three checks passing: compiled code is never slower than the simpler tier, every answer matches the reference browser's, and no real website loads slower.
JavaScript & JIT	Real websites are part of every test. A new check loads a set of saved copies of real sites (a large encyclopedia, a news site, a code-hosting site, a developer-docs site, a framework's docs site and others) many times with a change on and off, alternating so the machine's own drift cancels out, and measures how long each spends running JavaScript. A change that makes any page more than 3 percent slower now counts against the score, and the report names the functions that got faster or slower.
Memory & reading	No more freezes when a page cleans up. Floati frees memory the moment nothing uses it (reference counting). When a large structure died, such as an old copy of a page's virtual DOM, the page waited while every piece was freed. Now the page frees only a few dozen pieces itself and hands the rest to a helper thread, which works out what was used only by the dead structure and frees it, while anything still shared goes back to its owner. Dropping a 500,000-node tree used to stall the page for about 19 milliseconds; now it stalls for about 5 microseconds, and a virtual-DOM update benchmark runs about 17 percent faster.
Memory & reading	The memory allocator takes back memory freed by other threads in one step. Each page of memory now counts the blocks other threads have freed, so the owner can take the whole list back at once instead of walking it block by block.
JavaScript & JIT	Small functions that read their module's settings compile to machine code. A function like f(x) { return x * K + config.scale } called from a loop used to keep the loop in the slower tier, because the fast tier could only handle captured numbers. Captured objects now work too, and when nothing in the loop can change the setting it is read once before the loop. That loop runs 83 times faster, faster than the reference browser on the same test.
JavaScript & JIT	Destructuring in hot loops is up to 56 times faster. var {a, b} = options reads straight from the source object, and var [p, q] = [x, y] never builds the array at all.
Rendering	Object spread copies in one step. {...defaults, extra} copies a plain object's fields and layout at once instead of re-adding each one; that step is now about twice as fast as the reference browser's.
JavaScript & JIT	Text like 'item' + i is made once per place in the code. Each such spot keeps the strings it has made for small numbers, so building list keys and labels in a loop no longer allocates new text every time.
Memory & reading	Fixed: a loop could report the wrong length for a string it had just built. A cache keyed by memory address could answer with the previous string when the new one reused its memory; the cache now holds on to the string it describes.
JavaScript & JIT	Fixed: array destructuring, spread and for-of ignored a page that replaced the array iterator (Array.prototype[Symbol.iterator]). They now call the page's iterator, as the standard says.
JavaScript & JIT	Fixed: destructuring a number key from an array, as in var {0: first} = list, gave undefined. It now reads the element.