Welcome to read-model: we break the browser and JS libs on purpose

[rdd13r]

Demoscene

read-model is a benchmark fixture set.
It does "one thang and one thang only": bust a UI library SLA.

It came from an incompetent interviewer's perspective on "React dawg, man!"
His IT organization believes the problem lies in 10,000 node pages "React can't handle."

"How do you deal with too much data in your React UX?"

My answer, deeply unsatisfactory to them, was:

You don't. You architect and design first. 'Too much data' in read model is architectural incompetence, not a real-world problem.

Importantly:

1. What is the actual behavior of React given a boat-load of data?
2. Where is the actual crash boundary for browser, React, other libraries?
3. Is the problem "in the library," or is the problem "in the chair?"

Measuring to self-destruction

Real application performance is measured over millions of nodes. Described here:

• Site: https://mimis-gildi.github.io/read-model/
• Article: Read Model
• Article: “Smart” LIB
• Video: https://youtu.be/ocap_gdsrA0
• Short: https://youtube.com/shorts/NsStbi5V6Ow
• Blog: "adventures in engineering"

The bench

Each fixture renders an identical corporate data tree: Divisions → Groups → Teams → People.
The contract is ONE defined in Kotlin. The harness is implemented in Kotlin.
Measuring instruments are injected dependencies each particular to the library on the bench.
Comparative data is like so:

• Par: Chrome's own JSON in pretty-print.
• Pure TS: the etalon, the leanest possible DOM in TypeScript (TS).
• React Core: React stripped down to only sound decisions (TS, JSX).
• KobWeb and Compose HTML: Composable read models (Kotlin, Android).
• Next up: Svelte + XState - TBD.

The fixture contract is five verbs:

• build: construct the page DOM;
• reset: tear down the page DOM;
• unfold: expand each team's leaves;
• fold: collapse all leaves;
• uiFramework: how the fixture self-identifies.

The discussion

Architecture of the test itself.
We don't speculate about the libraries - that's for cogs.
We talk about clever ways to bench.
And there's plenty to discuss:

• What are the cutpoints and what is a fair slice take?
• What to do about radically different architectures: Qwik, or Svelte?
• What about "intended use" departure, i.e., XState wanting to cut Svelte at team level, thus taxing XState instead?
• What is the true parity between different concepts, i.e., hide versus unmount?
• Which library should we rip apart next?
• Reproductions: your Chrome version, machine type, Linux vs Os X, etc.

Valuable dialectic

• Bring evidence: profiles, numbers, code - and let's pair up or swarm on it.
• Bring ideas - and let's prototype on it.
• Bring a fixture - and let's beat up on it.

Live to code and code to live. - JRH

[rdd13r]

Svelte + XState: compiled nirvana or smaller funeral?

Svelte says the compiler does the work: it writes the DOM surgery up front, with no diffing and no ceremony.
On the XState side, we give every team its own actor, so impossible states stay impossible.

Put the two together over 300,000 nodes:

• Does "compiled" actually move the crash boundary, or does the browser die at the same place and only the stack trace gets shorter?
• Thousands of actors: is that architecture, or just a fancier way of stuffing the owl?
• Hide or unmount? Svelte's {#if} tears the subtree down. Is that fair against libraries that only toggle display?
• Who pays the tax? If XState wants to cut at team level, are we benching Svelte, or the actor system riding on its back?

My bet: it's still the chair, not the library. Prove me wrong.

Demoscene

• Grab the research issue: #2.
• Fork it, build the fixture, run the harness, and post the numbers: your Chrome version, your machine, your OS.
• Got a better place to slice, or a fairer way to compare? Make the case here, with evidence.