Eight frameworks. Three machines. The bad numbers too.

Method and limits

How these numbers were made, and what they cannot tell you.

When each machine was measured

One run each: Linux, macOS and Windows on 27 August 2026. They are very different hardware, which is the reason this page never puts a magnitude from one beside a magnitude from another.

The three machines. Host, run id and the date in it are fields in the extract. The processor column expands the host name and is not itself a reading.

The blend, exactly as implemented

For one metric, on one machine, take the lowest reading any framework achieved. Divide every framework's reading by it. That gives a multiple whose meaning does not depend on the hardware. Combine those multiples across the machines where the framework has a reading, using the geometric mean, because multiples compose by multiplying and an arithmetic average of them is dominated by the largest one:

ratio(f, machine) = value(f, machine) / min(value(*, machine))
blend(f)          = geometric_mean(ratio(f, machine) for machine in machines if f in machine and min(machine) > 0)

The logarithmic option

A logarithmic axis makes a bar's length stop being proportional to its value, which is exactly why bar charts default to linear here. It is offered because several of these metrics span three decades and the small end is unreadable otherwise. On that scale the axis runs from one decade below the smallest reading to the decade above the largest, and it is labelled with both bounds. A reading of exactly zero cannot be placed on a logarithmic axis at all; it is drawn at zero length with its real value written beside it.

Every caveat that qualifies a chart above

macOS counts GPU memory; Linux and Windows do not.

phys_footprint includes accelerator-backed pages. cgroup v2 and the Windows job object exclude them. On the empty window this is 73% of RayClay's macOS figure.

macOS charges no borrowed webview - but it does charge borrowed runtime.

WebKit ships with the OS, so every framework that renders in the system webview is credited with zero downloaded engine on that machine and only on that machine. That is a statement about webviews, not about macOS: Qt borrows 64.8 MiB there (99.7% of its 65.0 MiB bar), because Qt 6 is not part of macOS. Borrowed means any runtime the artefact does not contain, on any machine - Flutter's Linux bar is 100% borrowed with no webview in sight, and so are 72% of RayClay's.

Every active-use repeat on all three machines was graded comparable, and this page withheld three charts on the opposite belief.

The suite grades its own active-use window, per cell: whether the app was observed holding focus for the whole sample, and how many repeats it could use. Each machine kept 152 of 152 repeats, with 0 recorded unfocused, across every app and every data tier, and those counters read the same on all three. On the Windows machine, the one this was ever in doubt for, every one of the 56 mid-window cells also reports "focus was OBSERVED and held throughout". The repeat counts are in the extract as w1_repeats, w1_repeats_comparable and three more; the per-cell focus verdict is in the suite's own run report for this sweep. The counts alone would not have caught the case this is about. An earlier run on this same Windows machine, taken while another window held its foreground for the whole run, reads the same 152 comparable and 0 unfocused; what separates the two is that its cells report focus lost rather than held. Until 2026-08-27 this page refused to rank the Windows column of three charts, on a caveat that read the machine's desktop rather than either record. That caveat was withdrawn in full the same day, and the charts came back, which handed RayClay three placements it had not been getting. That is the direction this page is least entitled to move in on its own authority, so the evidence is published rather than described.

The Windows CPU column is quantised to the scheduler tick.

Each of the 8 Windows unfocused readings lands within 0.15% of a whole multiple of 15.625 ms per minute - one sixty-fourth of a second, the tick Windows accounts CPU time in. Only one of them is exactly a whole multiple - Qt's true zero; the rest are rates scaled to a per-minute window, so they land near a tick rather than on one. At that resolution the readings fall into pairs that the instrument cannot separate: Electron and Flutter on 11 ticks, Bun and Tauri on 13 ticks and NW.js and Wails on 14 ticks. Within a pair the two are separated on this page only by rounding. Read adjacent Windows CPU ranks as a tie unless the gap is at least one tick.

All three runs failed some of their own equivalence checks, and each report says to treat its comparisons as suspect until they are resolved.

The suite audits whether the eight apps are really doing the same work before it compares them, and on this sweep it exited non-zero on every machine: 17 on Linux, 4 on macOS and 11 on Windows. None of the failures names RayClay as the failing app, on any of the three, and that is read from the scope of every failing row rather than from a text search - "ZERO failures on ANY rig name RayClay as the failing app - verified by reading the SCOPE column of every failure row, not by counting text matches". The sentence is worth stating carefully, because it stopped being true for one sweep: macOS then flagged five frameworks, RayClay among them, for having been built before that machine's system libraries moved. Rebuilding cleared it for four of the five. It did not clear for Electron, which is measured through a downloaded runtime no rebuild here can re-fingerprint, so 3 of that machine's 4 failures are still that check, and 9 of Linux's 17 are the same check against Electron, Bun and NW.js. Every one of those is a framework this page charts. The full inventory, by machine and check, is Linux (9 build-environment, 4 pixel-liveness, 2 peer-theme, 1 conform-run, 1 empty-window-liveness), macOS (3 build-environment, 1 conform-run) and Windows (5 client-area, 3 client-area-parity, 2 analytics-locale-format, 1 conform-run) - this page does not claim to have named the ones that matter, because that judgement is the suite's and its reports carry it. Two are worth singling out because they bear directly on bars above. Tauri's Linux window paints one flat colour over the client area, which trips three separate checks across seven of those rows: it drew no content, and the surface it therefore shows is the toolkit default rather than the theme the other seven paint. One cause, seven rows. NW.js on Windows realises a window about 1.05 times the declared pixel count on the notepad and the empty window, which gives it more to draw than the frameworks it is charted against, and that one cuts in RayClay's favour.

GPU memory is published; GPU time is not, on purpose.

The memory an app holds on the graphics adapter is measured on Linux and Windows, and it is where RayClay does worst, so it is charted. How much GPU time each app burns is not published anywhere on this page, because it cannot be measured comparably: macOS has no per-process GPU-time counter that works, three separate readers having been tested and refused; the Linux counter returned 11 of the 24 in-use readings it should have taken, from a poll slow enough to miss a quiet app, and it is blind to the second graphics adapter in that machine. Two machines, one of them 54% empty, is not a comparison. An absent GPU-time bar means the instrument failed, never that the app used none.

Tauri's Linux window figures are withdrawn by the people who measured them, and this page still draws them.

On the Linux machine Tauri's WebKitGTK window paints one flat colour over the whole client area, so every figure taken with that window on screen reads artificially cheap: its Linux memory, CPU, GPU memory and time-to-window bars are all weaker evidence, biased in Tauri's favour. Its Linux disk figures are unaffected and stand. They are drawn rather than dropped deliberately: removing them would move RayClay from third to second on Linux startup and from fourth to third on Linux GPU memory, and a page should not improve its own subject's rank by deleting a competitor's inconvenient row. Read those Tauri cells as a floor, not a reading.

Qt is not the same version on every machine.

6.10.3 on Linux and Windows and 6.11.1 on macOS. Every other framework is pinned to one version across all three. This one is not sloppiness and it is not fixable by pinning: Qt is linked dynamically, so the Qt on the machine is the Qt the app runs, and the system version is the honest number to record.

The RayClay row is a build, not a release number.

Every competitor names a released version; RayClay names 876ff4b9add9, the leading hex of the SHA-256 of the single header the three apps were compiled against, identical on all three machines. The site publishes RayClay as v0.8, and this says which build of it these numbers came from. Measuring a header-only library against the file itself is the only identifier that cannot drift from what was actually compiled.

One run per machine, and the launch-derived figures in it are already folded across repeats.

The extract carries one run_id per machine and no duplicated (os, framework, app, metric, arm) row, which is why there are no error bars here: the spread was folded away before the extract was cut rather than skipped. The suite launches each application once per repeat before starting the next, discards a warmup, and folds with a median rather than a mean, so one unlucky launch cannot carry a bar. That covers the memory, CPU and startup figures and not the disk ones, which are file sizes measured once and never launched; the extract's producer column is how you tell those two apart. What this page cannot show you either way is the spread, only its centre, because the fold happened upstream of the file it publishes.

Storage latency is measured and is deliberately not published.

The suite exercises a CRUD workload and the extract behind this page could carry it. It does not, because RayClay does not implement that storage layer - the application developer writes it. A CRUD number would compare eight app authors, not eight frameworks, and putting it on a framework comparison would be a category error however carefully the arithmetic was done. They are dropped from the data behind this page, not merely left off the charts.

Versions

One row per framework, one column per machine, read out of the extract. RayClay's is not a version string at all: it is the SHA-256 prefix of the exact rayclay.h that was compiled, because a version string can name two different builds and a hash cannot. All three machines carry the same one, which is what makes these three runs one sweep rather than three unrelated runs.

What was built, per machine.

Provenance, and the data itself

Every measurement charted on this page comes from one file, and you can download it: the full extract - 2,911 rows, 372.2 KiB, tab-separated, one reading per row with its machine, app, framework, metric and arm intact. It is served from this site rather than linked away, and the copy you get is written by the same build that drew the bars, from the same bytes, so it cannot drift from what you see above.

Nothing here asks you to take a chart on trust. To re-derive a bar, filter on four columns, not three: one metric, one app_type, one os and one arm. The arm is the one people leave out, and leaving it out is why a filter can come back with two rows for the same framework - a cold-start reading and an idle one, say. Every table on this page names the arm its chart used, in the caption. Match it and you get one value per framework.

Then divide each framework's value by the smallest in that group: that ratio is the bar. The blended bar is the geometric mean of those ratios across the machines a framework has a reading on - never an average of the raw magnitudes, which is the one operation this data does not support, and never an arithmetic average of the ratios either, which would let the single largest machine decide the bar. One chart needs a step before the division and says so beside itself: unfocused CPU has machines where the best reading is exactly zero, which makes a ratio undefined - those machines are dropped from that metric's blend rather than floored, and the chart names them.

It is a pinned extract of the RayClay competitor benchmark suite: the same rows every chart above is computed from, so any bar here can be checked against it.

Three machines, one run each, and a jester's job description: tell the king the number he did not want.