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.
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.