Web Showdown 2026: Read Model

What web technology competent teams would use in 2026?

We had an awesome weekend on the Scene — 90 minutes of pure discovery among such coders. Hope you had a good weekend too! And we selected the final technologies for a fun, purely hands-on exploratory load test proving:

"In 2026 you should use these to present data in production."

And an Easter Egg I’ll mention later.

Some new library options showed up recently. It’s always useful to know which SLAs can push architecture boundaries. This is the opposite to the typical "your big corp needs this framework" — purely hackers for hackers fun. We just ran a 4-deep nested 4_000_000-object data frame to self-destruction.

Before you laugh and click away, I know that pushing excessive data is NEVER a thing in any competent company. An impossible scenario because Read Model doesn’t process data: its constraints are always owned by the Aggregate. Besides, it’s there to impress a human — export formats and dedicated modules deal with grids, notebooks, and sheets.
This humorous article explains how this wild idea has come to be.

Structural Limitations:

We need a place to Draw a Boundary.

The community chose Google because — First) its architectural cleanliness is well known. The design of legacy Gmail shows clear data weight awareness. Pristine! The Read Model boundary made into an API: the supplier (Aggregate) hands back a render-ready model at exactly the requested weight. The client never processes a firehose because the API structurally forbids asking for one.

• Format tiers on messages.get:
  minimal (id + labels only) → metadata (+ headers) → fully parsed payload → raw.
  (Four explicit data-weight levels.)

• Partial response via the fields parameter — request only the needed fields.

• Pagination: maxResults (default 100, hard cap of 500) + the nextPageToken.

• gzip, patch requests (send ONLY the changed fields); batching — all per the performance guideline.

And this is way before HAL!

The rewritten Gmail demonstrated an architectural shift to exported behavior patterns. The extension and behavior architecture rewrite was all about aggregate-owned behavior. Contextual Gadgets replaced by Google Workspace Add-ons and CardService — behavior runs entirely server-side and the client renders only declarative Cards (Aurinko teardown). The push via Cloud Pub/Sub watch() replaced client polling.

Perfect example of exported behavior: the client owns no behavior, just presents a server-authored declarative model. They’re not going to have the "too much data for the Read Model" — are they now?

Second) Google Chrome browser has very high, easily verifiable boundaries on DOM:

• Steep degradation at about 50,000 live nodes;

• Severe, hard-to-fix lag at 100,000 live nodes.

Chrome’s superlinear cost on layout, style, recalculations is about the best on object models.

Baseline) is React 19.2. Not just because it was asked about in the Stuffing the Owl article. React’s incredibly accessible thus common and popular. This is NOT a library for competence or performance optimization. It is popular because it can be fully mastered (not just learned) in a single weekend. As a bonus, due to its extreme simplicity, ubiquity, and relatively complete functionality the library is easy to "standardize" in the risk-averse Corporate America.

React 16 dropped its recursive-tailrec-wannabe VDOM management in favor of an interruptible iterative loop specifically to escape recursion — the Fiber engine. This and some bugfixes bought the library around 10,000 live nodes before sure death. Current drop features the new stable React Compiler, Activity (rendered when in background), Partial Pre-rendering (PPR) with static plus dynamic render, all the Performance Tracks developer trinkets I’d surely welcome. Soon we shall see what all that jazz buys us! This will be our base number to always do better on.

Finally) we shall see what to do instead of Stuffing the Owl. If you trade you may know of tastytrade, very competent software — firehose of low latency data served to limited biological eyes. The four million test exists to share ideas on what one can do when absurd is actually required.
There’s no reason why Acme Insurance should have unhappy owls.
(Psst. Google Home API is also a good example.^[1])

1. 1,000 → 5,000 with expand;

2. 5,000 → 15,000 with expand;

3. 15,000 → 100,000 till crash.

4. 4_000_000 data processing UX.

So, yes — 'Read Model side data coping' is being deliberately ignorant of the boundary.
We do not advocate this antipattern in any possible way — we drive it to self-destruction for one reason only: you cannot publish an SLA number you have never crashed into.

These are just our technology TEST boundary conditions.
(Please code with me despite 🤗 — it’s fun!)

Chosen Technologies

Two families, split on the one line that decides the whole test:
does it paint into the browser’s own DOM,
or does it draw its own pixels off to the side?

DOM: live and die by Chrome’s node ceiling:

• React 19.2 — the baseline ← poor Owl.

• SolidJS — fine-grained reactivity, no VDOM.

• Svelte — compiled, no runtime framework.

• vanilla-JS — the control group; handwritten DOM.

• Kobweb — Kotlin, Compose HTML into real DOM. ← Our darling!

Nothing production-ready off DOM yet.

---

Kudos!! David (bitspittle of Varabyte) is a friend and a legendary wizard hacker,
Kobweb is THE way to build performant Read Model especially in a startup.
Watch his Kotlin Conf 2025 presentation to understand why you save time and money.
Composable SEO-friendly DOM power in type-safe pragmatic language + tools + automation.

Notes: I was wrong about KVision in my comments, it’s not rewritten for Wasm — that is Kilua.

---

What Isn’t Considered

DOM:

• KVision — we supersede this DOM only library with Kilua.

• Vue — I personally like this library; it just doesn’t add anything to the test (see React).

• Angular — marginalized as outdated Ivy incremental DOM.

• Leptos (Rust, compile Wasm render DOM) — See volunteering callout.

• Dioxus (Rust, compile Wasm render DOM) — See volunteering callout.

• Kilua (JS) — Compose-style DOM.

• Kilua (compile Wasm render DOM) — still just DOM.

Wasm:

• Compose Multiplatform for Web (Skia canvas, Wasm) — I have a lot to gripe about this one on. Having produced a lot of multiplatform software with KMP I loved it.
  EXCEPT this. bitspittle explains it best here:
  Compose Multiplatform for Web: An Amazing Framework That Maybe You Shouldn’t Use.

• Flutter Web (CanvasKit / Skwasm — Skia to Wasm) — same off-DOM bargain; Skwasm even paints off-thread in a worker. Beautiful for an app, disqualified for a public Read Model: no SEO, no accessibility tree, a fat renderer to download.

• egui / eframe (Rust, Wasm → WebGPU/WebGL2 canvas) — immediate-mode; paints every pixel itself, owns no DOM.

• Makepad (Rust, Wasm → WebGL/GPU shaders) — furthest from a DOM Read Model there is.

Volunteering: Nobody picked up Rust in our clique. Ping me if you care to!

The Fixture

If you read so far then you’d noticed something rather peculiar: "so much for the new tech!"^[2]
WebAssembly isn’t an option so all the tests are on DOM for this run. Here’s our setup:

1. Ktor application serves all the test data for benchmarking — Aggregate 1;

2. Ktor captures all the test metrics from corresponding modules under test — Aggregate 2;

3. Ktor serves the control plane landing page application for the core function;

4. Ktor serves all the modules under test from single multimodule project.

So we have one beautiful polyglot project and all is decided on the spot!

Project planned as part of Mímis Gildi org — standard ops included.

What Say You?

Please DM if you want to take a module!

We start on August 7th!

Here is the current roster August 2nd

• Project Manifest — rdd13r required

• Module Groups — rdd13r required

• Ktor Aggregate — rdd13r required

• Micro Frontends — peer claimed (rdd13r backup)

• Controlplane SPA — rdd13r required

• React SPA — rdd13r required

• SolidJS — vacant

• Svelte — peer claimed

• vanilla-JS — vacant

• Kobweb — peer claimed (contested, may pair, rdd13r as backups)

Here are optional modules that can be added

• KVision — vacant

• Vue — vacant

• Angular — vacant

• Leptos — vacant

• Dioxus — vacant

• Kilua — vacant

• KMP Web — vacant (not favored)

• Flutter Web — vacant (not favored)

• egui / eframe — vacant

• Makepad — potentially claimed / vacant (TBD)

Happy Monday!
And have a good week 😉

---

1. The current Google Home cloud-to-cloud API — not the old Nest stack — is textbook exported behavior. Device capabilities are _declared_ as traits during a SYNC intent; Google dispatches SYNC / QUERY / EXECUTE intents to the partner cloud that _owns_ the behavior; and Home Graph is a projection that stores only what Report State sends — a Read Model in Google’s own plumbing. The kicker: control and data ride separate rails — an EXECUTE hands back a `cameraStreamAccessUrl` and the client streams the firehose _directly_, peer-to-peer, so it never touches the control channel. The heavy data never rides the Read Model.

2. Give Wasm its due — the real win is *server-side*: WASI, edge, serverless with single-digit-millisecond cold starts. The New Stack’s See What WebAssembly Can Do in 2025 and TechTarget’s more sober takes shape both hype _that_ Wasm, and rightly. But notice what they never claim: Wasm painting UIs off-DOM to "save the web front-end." That claim lived in the blog tier that has since been quietly deleted. Nobody reputable put Wasm in front of a public Read Model — which is why this showdown fields zero off-DOM contenders. So much for the new tech.