v0.1.32026 Sep 2026·Rendering, JavaScript & JIT, Web APIs & DOM, Networking, Memory & reading

Pages no longer freeze while a script waits on the network

A script that waited on the network inside a try block used to freeze every script on the page until the server answered. It now waits in the background, the way the reference browser does, and on the news sites we measured that was most of the time a page spent running scripts. JavaScript is also faster across the board, and our JavaScript performance number is now measured against the reference JavaScript runtime on 42 real-world workloads instead of estimated. Measured, it is 50, not the 74 we had estimated.

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

Networking	An await inside try/catch no longer stops the page. await pauses one function until a value arrives, usually from the network; when that await sat inside a try block, Floati paused every script on the page instead, for up to eight seconds. Profiling real pages showed this was 56 to 93 percent of what counted as script time on a news site, a second news site and a browser-support site. It now pauses only that function, and the order in which async code runs matches the reference browser and runtime in every case we tested.
JavaScript & JIT	await on a plain value (await 0, await null) now yields to other work first, as the standard requires, instead of running straight on. On a browser-support site this is visible: an ad box that used to cover the site navigation no longer does, and the page renders closer to the reference browser.
Memory & reading	Building text piece by piece is fast. Code that grows a string with += in a loop used to copy the whole string on every step; long strings are now joined lazily (a rope: the pieces are remembered and copied once, when the text is read). 100,000 appends went from 2 seconds to 45 milliseconds.
JavaScript & JIT	Walking trees and lists runs as machine code. Recursive functions that follow object links or index into arrays (a tree sum, a linked list walk) are now compiled by Floati's native compiler, up to 6.5 times faster, and closures that update a variable they captured run natively too, 30 times faster than before.
JavaScript & JIT	Array callbacks run inline. map, filter, forEach, reduce, find, findIndex, some and every now run a simple callback directly inside their loop instead of making a full function call per element, including callbacks that read or update outer variables: up to 3.7 times faster.
Web APIs & DOM	Function calls do less work. Calling a function used to set up a hash table for its variables and build an arguments object every time; it now uses a small preallocated frame and builds arguments only when the function actually reads it. Reading a built-in method such as indexOf no longer allocates, and blocks that declare no variables no longer create a scope.
Rendering	eval behaves correctly: variables declared with let, const or class inside eval stay inside it, and eval in strict code keeps its own var declarations, as in every other browser.
JavaScript & JIT	An honest JavaScript performance score. The number on this page is now computed by a benchmark suite that runs 42 real-world workloads (JSON, regular expressions, string building, classes, closures, Map and Set, sorting, a virtual DOM diff, typed arrays and more) on Floati and on the reference JavaScript runtime, and scores each one by how close we are. It went down because it is measured now: numeric code already matches or beats the reference JavaScript engine, while classes, generators and exception-heavy code still run several times slower. Those are next.