Two different kinds of number, both measured against real, running code rather than claimed: how fast the framework runs, and how often an AI actually generates it correctly on the first try. If a number below can't be verified by running something real in this repo, it isn't on this page.
The same 4 operations (create 1,000 rows, update every 10th, swap two rows, clear) against real implementations of the identical table in Kopular, vanilla JS, React, and Angular — a benchmarks/ directory in this repo runs all four for real. Measured on one Apple Silicon Mac, headless Chromium, 2 warmup + 15 measured trials, median reported. Two consecutive runs on the same machine varied by up to ~20% on some cells — treat every number here as "roughly this," not a precise, repeatable measurement.
| Implementation | Create 1,000 rows | Update every 10th row | Swap rows | Clear |
|---|---|---|---|---|
| Vanilla JS | 19.2 ms | 11.9 ms | 16.1 ms | 16.2 ms |
| Kopular | 20.0 ms | 12.2 ms | 19.9 ms | 12.2 ms |
| Angular | 21.3 ms | 11.7 ms | 16.2 ms | 16.2 ms |
| React | 22.9 ms | 13.4 ms | 20.9 ms | 11.2 ms |
Kopular is competitive with, or faster than, React on every one of the four operations, and within noise of vanilla JS/Angular on three of the four (Swap is the one where Kopular is measurably behind the hand-optimized/Angular floor, though still ahead of React).
Kopular's Update() diffs a component's new VElement tree against the previous one and patches only what changed, reusing a real DOM node wherever its tag stays the same — not a full subtree rebuild on every re-render, the way earlier versions of this framework worked. A list child keeps its own real node across a reorder by giving it a stable VElement.Id (used as a real DOM-style key); without one, a reordered list still renders correctly, but a given item's node isn't guaranteed to follow its data — the same trade Angular/React make with their own @for track/key props, not a Kopular-specific gap.
Three things keep the diff engine fast at scale: event listeners are only swapped when the handler itself actually changes, list reconciliation runs in O(n) rather than O(n²), and a reorder only touches the DOM for rows that actually moved. These benchmarks are re-run against every release, not measured once and left to go stale.
Measured directly from this site's own compiled output (gzip -c on the real files it ships), not a claimed figure:
| Runtime | Gzipped |
|---|---|
Kopular — Component + Router + DOM bindings (the minimum any routed app needs) | ~0.9 KB |
Kopular — everything (+ Http, Forms, structural directives) | ~2.0 KB |
| React + ReactDOM (production runtime, no app code) | ~45 KB* |
| Angular (core framework, minimum) | ~130 KB+* |
*Commonly-cited approximate figures for recent versions, not independently re-measured here — Kopular's own numbers above are. Neither includes your own application code, which every framework adds on top; there's no bundler step to measure for Kopular specifically, since ks build emits plain ES modules directly.
Kopular's other headline claim — "AI-optimized" — only means something if it's backed by real testing, not just a framework that reads simply. This repo's ai-eval/ directory runs 12 realistic application-building tasks against a fresh AI session, no retries, no hints beyond each framework's own published docs, and checks the result against a pre-written test suite.
| Task | KopScript + Kopular |
|---|---|
| 1. Todo list | PASS |
| 2. Multi-field form validation | PASS |
| 3. Debounced live search | PASS |
| 4. Routing + guarded admin route | PASS |
5. Generic Stack<T> | PASS |
| 6. Shopping cart | PASS |
| 7. Nullable-heavy find-by-id | PASS |
| 8. Tabs UI | PASS |
| 9. Paginated list | PASS |
| 10. Reusable combined validator | PASS |
| 11. Shared service (DI) | PASS |
12. Enum state machine + match | PASS |
| Total | 12/12 (100%) |
See ai-eval/README.md for the full methodology and every task's spec and test suite.