The straight answer

Where Lilscript wins—and where it mostly ties.

Small typed programs currently show clear size wins. Complete package entrypoints are usually much closer. SolidLil’s exact Core, Store, client Web, and full Web-compatibility distribution bundles pass their Brotli objective. Raw and gzip remain visible diagnostics for those Brotli-selected artifacts. Its historical LSX app stays outside the verified aggregate. The accessible Lilastro marketplace is effectively the same compressed size as Astro.

Calculating verified comparisons…

Exact framework browser entries

Parity and optimization are separate columns

All four SolidLil rows preserve their declared public ABI and pass differential behavior. Client Web excludes SSR and hydration; full Web compatibility keeps all 73 browser exports as a separate row. Every row passes the declared Brotli objective; raw and gzip are reported as diagnostics for that Brotli-selected artifact.

The gate

135/135 Core, Web, and Store exports and 469/469 unchanged upstream tests.

The boundary

These are reusable open-world bundles. The separate closed-world diagnostic verifies that every runtime export can be mangled when the consumer graph is complete.

Select and compare the SolidLil surfaces

Across every publishable row

A useful average, with the warning attached

The overview normalizes each verified case against its fair control, then averages the percentage differences. It is a directional scorecard—not a promise that an arbitrary JavaScript app becomes that much smaller.

Selection warning: this includes only behavior-verified rows whose scope is publishable. Unsupported and partial package experiments are excluded rather than counted as wins. Different categories use different fair controls, so the category results below matter more than the single overall number.

Small scripts and compiler kernels

Double-digit savings are common here

These are the cleanest compiler comparisons: the algorithms and outputs match, Closure receives the readable JavaScript control, and Lilscript owns the typed whole-program input.

What this proves

Lilscript can erase typed abstractions and select compact output better than Closure on these bounded cases.

What it does not prove

Six tiny scripts and five compiler workloads do not predict framework overhead, network waterfalls, rendering speed, or arbitrary npm compatibility.

Complete package work

The advantage shrinks as compatibility becomes stricter

Two views matter: translated complete package surfaces show what deeper language knowledge can remove; exact published ESM entrypoints show the cost when the public JavaScript boundary must remain intact.

The win

Complete selected ports are smaller without exceeding the lab’s 5% material runtime or retained-memory gate.

The tradeoff

Only four of ten audited popular root entrypoints currently qualify as exact. Partial Preact, Solid, Immer, Redux Toolkit, Zod, and Acorn work is not counted as compatibility.

Open the package-by-package evidence

Larger UI projects

The two real apps tell different stories

A large percentage is only meaningful beside its compatibility boundary. A tiny percentage can still be valuable when both sides implement the same complete experience.

Lastro is the application experiment represented by Parcel Market; it uses the Lilastro result and is not counted as a second bundle win. Neither UI project currently supplies a browser-rendering performance comparison.

Reproducible detail

Open the evidence you need

The tables, per-workload results, confidence gates, and optimizer ablations remain below. They are collapsed so methodology does not hide the answer.

Five readable compiler workloadsTotals, codecs, runtime ratios, and per-compiler rows

Five-workload compiler corpus

Comparable totals

Loading generated benchmark summary.

Six mechanically paired small scriptsBrotli gate and 400-sample browser confidence gate

Mechanical source parity

Generated Closure gate

Loading generated paired benchmark metadata.

Both readable sources come from the same typed integer expression and statement schema. This lane compiles a Brotli-target LilScript artifact and gates its Brotli-11 size against Closure ADVANCED. Raw and gzip-9 measurements of that same deploy artifact are diagnostics, not additional objectives.

Optimizer ablationsIsolated pass wins, ties, and codec tradeoffs

Single-pass ablation

Interprocedural finite values

Both artifacts disable inlining and scalar replacement and execute the same JavaScript/native contract. Only finite_value_propagation changes, isolating branch, field, and signature cleanup exposed by the bounded lattice.

Variant Brotli-11 · primary Gzip-9 Raw
Finite values enabled 77 108 143
Finite values disabled 118 155 216

Whole-program ablation

Identical private functions

Both builds disable inlining and execute to 95660. The enabled build folds one residual directly called private implementation after specialization settles; observable function identities are excluded.

Variant Brotli-11 · primary Gzip-9 Raw
Folding enabled 105 129 123
Folding disabled 111 139 177

Proof-driven IR ablation

Private implementation sharing

Specialized private functions are redirected to existing broader scalar and higher-order implementations only after typed bindings make their normalized SSA/CFG exactly equal. Both builds execute to 3940336; observable function identities remain excluded.

Variant Brotli-11 · primary Gzip-9 Raw
Subsumption enabled 172 201 351
Subsumption disabled 179 217 445

Codec-layout ablation

Declaration clustering

Dynamic programming proposes an order for four interleaved function families. Source order remains a complete-artifact candidate, both builds execute to -1393288640, and raw bytes remain unchanged.

Variant Brotli-11 · primary Gzip-9 Raw
Layout search enabled 362 454 1,133
Source order 369 460 1,133

External-profile ablation

Higher-order specialization

Both builds disable ordinary inlining and execute the same 10,000-iteration callback contract. The enabled build uses a versioned hot-loop profile and bounded call-site specialization; the static build omits that pass.

Variant Brotli-11 · primary Gzip-9 Raw
Profile-guided specialization 77 104 107
Static higher-order call 80 107 111

This isolated fixture wins four raw bytes and three bytes under both codecs. It demonstrates one bounded decision, not a universal PGO advantage.

Optimizer-IR ablation

Codec-selected inlining

Both artifacts execute the same JavaScript/native contract with identical final-emission search. The enabled build lets configured inlining compete with an outlined IR; Brotli retains the shared helper.

Variant Brotli-11 · primary Gzip-9 Raw
Inlining IR variants enabled 83 113 219
Inlining IR variants disabled 109 144 267

Emitter ablation

Codec-selected loop spelling

An order-sensitive control-flow fixture executes to 137 in both builds. The broader do/update/structural search now reaches the same artifact with the legacy while/for dimension enabled or disabled, so this is a non-regression gate rather than a size-win claim. The complete MurmurHash port is also byte-identical.

Variant Brotli-11 · primary Gzip-9 Raw
Codec-selected spelling 178 243 527
Frequency heuristic 178 243 527

Partial-inlining ablation

Reusable closure factories

Twelve capture signatures execute through JavaScript, C, and native outputs. The enabled build adds a factory-preserving IR while retaining both configured and fully outlined optimizer baselines.

Variant Brotli-11 · primary Gzip-9 Raw
Factory IR variants enabled 176 255 648
Factory IR variants disabled 177 244 677

The default objective is Brotli-11: factory preservation wins raw and Brotli while spending 11 gzip bytes. Gzip-targeted builds score the fully outlined IR independently.

SSA emitter ablation

Range-proven increments

The complete Levenshtein port executes in both builds. Prefix and postfix forms compete only for one-use loop-carried adds whose range proves signed-i32 normalization unnecessary.

Variant Brotli-11 · primary Gzip-9 Raw
Mutation spelling selected 777 900 1582
Assignment spelling only 780 899 1583

The default Brotli objective wins one raw byte and three Brotli bytes while spending one gzip byte. Assignment spelling remains available when gzip is selected.

Complete npm ports

Library compatibility lab

Six version-pinned apps covering Motion easing, clamp, lerp, string hashing, edit distance, and MurmurHash run translated upstream assertions, dense differential tests, Vite and Closure builds, and LilScript JavaScript/C/native outputs.

Open library results
Per-workload compiler tablesReactive store, events, binary memory, modules, and motion helpers

Typed signal graph

Reactive store

The compiler comparison uses equivalent signal classes. A real Alien Signals application appears only in the separate Vite context.

reactive:1890621774:408

Typed event dispatcher

Event pipeline

The compiler comparison uses equivalent dispatchers. A real mitt application appears only in the separate Vite context.

events:975625712:9718960

Binary memory

Binary telemetry

Equivalent ArrayBuffer, SharedArrayBuffer, Uint8Array, checksum, and signed-integer behavior without a dependency.

binary:446359193:32

Static modules

Module pricing

Equivalent side effects, imports, aggregates, unused exports, cross-file inlining, and dead-code elimination.

module:init / modules:593759979:4940

Animation compiler kernel

Value mixing, wrapping, and staggering

The comparable rows implement the same three-helper value algorithm. The specialized LilScript row diagnoses optimizer headroom. A separate Motion 13 Vite app also exercises its deterministic spring generator as context only.

motion:14400000:28719240:880000

Compatibility status

Motion 13 is a candidate surface, not a full port

The current npm package exposes 312 root exports and spans approximately 64,000 source lines across Motion, Motion Utils, Motion DOM, and Framer Motion. The monorepo now contains open/closed-world Motion JS/DOM work and openable paired fixtures, while React/Vue entrypoints and the full published root contract remain outside the claim. The independently published two-export @motionone/easing package has a separate complete measured port.

The versioned scope, missing language/platform facilities, port sequence, and no-false-claim gates are documented in docs/motion-compatibility.md.

Method

Generated from checked evidence

Loading benchmark metadata.

All displayed measurements come from benchmarks/apps/RESULTS.md through checked-in generated data. The harness runs methodology tests after behavior verification.