Benchmarks#

leptoskit is benchmarked against itself on every pull request, so a change that slows it down is caught before it merges. The tables on this page are the other half: a comparison, run on demand, of what leptoskit costs next to the alternatives. They compare leptoskit with plain React in the DOM, React Native rendered by react-native-web, Flutter web, and vanilla JS as the floor, plus the build-speed face-off against cargo-leptos.

The methodology lives in benchmarks/README.md: the scenario set follows the js-framework-benchmark keyed table, every scenario verifies the expected DOM state before its duration counts, and the user-facing metrics — time to first render, click throughput, transfer size, heap — are first-class alongside it.

leptoskit, React Native, Lynx, and Flutter#

If you are choosing a way to ship one interface to phones, desktops, and the web, the four serious options make different bets. They differ in where your code runs, what draws the pixels, and what crosses between the two on every update. This section compares leptoskit with the latest releases of React Native, Lynx, and Flutter in two ways:

• How each one is built. A table of the architecture: how messages cross from your code to the screen, and what each framework supports.
• What each one measures. The same app is built idiomatically in every framework, run through the same scenarios on every platform, and timed from screen recordings. That way, a framework's own frame counter never decides the result.

All four apps use the same contract. Each one shows a small coloured square whose colour marks when a scenario starts and finishes. The recording shows which frames actually reached the screen, and when. The method, the scenarios, and every app's source are in benchmarks/arena.

How they are built#

What the arena measures#

Frame numbers are presented frames per second and hitch time: milliseconds of lateness per second of motion, as Apple defines it. Under 5 ms/s feels smooth and over 10 ms/s is visible stutter. Simulators, emulators, and headless browsers run on a desktop CPU without the phone's GPU timing. Their tables are marked shape only: they show which framework is ahead, not the numbers a phone would show.

iOS#

Not measured yet.

Android#

Measured 2026-11-01 on Seeker, Android 16 (physical), 5 runs per framework, medians; leptoskit 0.1.0, React Native 0.88.1, Lynx 4.2.0, Flutter 3.47.8.

1. Big bang, every framework: each app times its own state change to its earliest after-frame hook, and the results file carries the hook it used. The recording cannot time these steps any more: leptoskit's land in one or two display frames, so Android's recorder often encodes neither beacon, and a window it cannot see is not a window it can time. create_to_pixel_ms, update_to_pixel_ms, and clear_to_pixel_ms are still recorded wherever the frames are there.

macOS#

Not measured yet.

Windows#

Not measured yet.

Linux#

Not measured yet.

Web#

Not measured yet.

App size: minimal, medium, and large#

Every framework builds the same three apps from one specification:

• minimal: one counter screen;
• medium: 12 screens, made up of a home menu and three each of counter, list, form, and detail screens;
• large: the same mix at 120 screens.

Every screen has its own labels and data, as in a real app. Navigation is a piece of state, not a routing library, so no framework pays for a dependency the others skip. "Each extra screen" is the difference between large and medium, divided by the 108 screens between them. It separates what a framework costs before you write anything from what your code adds.

Built 2026-10-28 on darwin aarch64. Android: the arm64-v8a release APK. iOS: the unsigned arm64 device .app. macOS: the .app bundle. Web: bytes transferred on first load, gzip-compressed as served.

Runtime in the browser#

All fixtures implement the same keyed-table app with the same labels. Durations are medians over 7 fresh-page runs in headless Chromium; transfer sizes are gzip-compressed, as served. Flutter web renders to a canvas, so its table scenarios cannot be DOM-verified — it reports startup, transfer, and memory only.

Measured 2026-10-20 on darwin aarch64, 12 cores, headless Chrome/155; 7 runs per app, medians.

Build speed#

The same app sources — byte-identical, enforced at benchmark time — built through each toolchain on the same machine. Warm is a no-change rebuild after a priming build; incremental bumps the client source first (the loop developers live in); cold removes the target directory and output entirely. The leptoskit pipeline runs wasm-bindgen in-process and skips it entirely when the compiled wasm is unchanged, which is where the warm and incremental gaps come from.

Measured 2026-10-20 on darwin aarch64, 12 cores; hyperfine wall-clock medians, tools interleaved per round.

The view layer, the wasm runtime, and a JavaScript baseline#

The browser numbers above measure leptos rendering to the DOM. On iOS and Android, leptoskit apps do something else entirely: the interface is a wasm module running in wasmi — an interpreter, because iOS forbids JIT compilation — driving leptoskit's own view layer (leptoskit_native over the leptoskit_yoga layout engine) through a versioned ABI. This table measures those layers directly, with one binary that runs on the host, in the iOS simulator, and on an Android emulator.

Three layers, one workload — a 1,000-row list, the same shape the browser benchmark renders:

• native and yoga — the view layer on its own: build the element tree, commit it (resolve, create, lay out), relayout after a viewport change, diff a partial update and a removal, resolve Tailwind classes, dispatch events, hit-test, and the layout engine standalone (flat, grid, incremental).
• wasm — the shipped path: a Rust guest compiled to wasm32-unknown-unknown (benchmarks/native/guest) builds the list, handles presses, and re-renders through the real rendering ABI, interpreted by wasmi, with the host decoding JSON props and committing to the surface.
• js — the same guest written in JavaScript, call for call, run in QuickJS: a bytecode interpreter, the same execution class as the Hermes and JavaScriptCore engines a React Native app runs on where JIT is unavailable. It drives the same ABI into the same surface, so the only variable is the layer running the app logic. QuickJS is a stand-in for that class, not a Hermes measurement.

Every scenario verifies the surface afterwards (row counts, label text), and the host side is identical for the wasm and JavaScript columns, so differences between them are guest-layer differences. A commit() rebuilds only the nodes the guest changed since its last commit, so a round trip that updates one label costs little more than the guest's own work.

Measured per platform — host: 2026-10-21 on macos aarch64, 12 cores, 15 runs; ios: 2026-10-20 on ios aarch64, 12 cores, 15 runs; android: 2026-10-20 on android x86_64, 2 cores, 15 runs; medians.

The iOS and Android columns come from the iOS simulator and an Android emulator. Simulators and emulators execute on the host CPU: they verify the pipeline and expose platform behaviour, but physical-device numbers differ.

App size#

What a minimal app weighs on every platform leptoskit publishes to. Each row is the artifact a fresh leptoskit new scaffold produces in a release build with the default plugin set, measured by walking what actually ships: the browser's initial load (brotli, as served), the macOS and iOS application bundles, and the Android APK. The platform build tools print the same report at the end of every leptoskit native build --release.

Measured 2026-10-22 on darwin aarch64; the scaffolded app, release builds, default plugins.

The host code column is the linked binary (the Rust runtime: wasmi, the view layer, yoga, the plugins, and code push's TLS) on Apple platforms and the uncompressed lib*.so inside the APK on Android; the wasm guest is the app's compiled interface, carried raw on macOS and gzipped inside the app.lkb code push baseline on iOS and Android. Numbers are from one machine and one Xcode/NDK pair — treat them as the shape of a leptoskit app, not a promise; the committed JSON carries the exact inputs.

Formatting#

leptoskit format has its own benchmarks, compared against leptosfmt in the formatting guide: a formatted 4,178-line file in 84 ms, where rustfmt alone takes 67 ms, and an unchanged workspace of 335 files checked in 30 ms.