Reviewing a diff the size of a small city.

The premise

Most rich UIs ship the data to the user. We don't.

The browser is an excellent renderer and a hostile state store. The instant a diff with two hundred thousand lines lands as a JSON blob, you've shipped twenty megabytes, spent thirty seconds parsing it, and handed the page to a framework that now has to re‑render the universe every time the user scrolls.

largediff inverts that. The backend is the single source of truth — it owns the diff, the parse tree, the collapse state, the highlight ranges. The frontend is a projection: a few signals, a couple thousand DOM nodes, no parsers, no virtual‑DOM accountant. When something changes on the server, a short SSE message lands and the page morphs.

The fat morph

One render path. One payload. The whole UI, every push.

For most of the project's life the wire carried three kinds of events per push: a morph for the diff window, a signals patch for active-file metadata and imperative scrolls, and a second morph for the sidebar slice. Each had its own emit gate, its own skip‑when‑unchanged fingerprint, and its own contract with the client. It was efficient on the wire. It was also a steady source of bugs the moment you stopped staring at it.

The version live today replaces those three events with one:

// every command handler ends here
writer.send("datastar-patch-elements", [
  "selector #app",
  "mode inner",
  ...renderAppInner(session, deps).split("
")
    .map(line => "elements " + line),
].join("
"));

Every push re‑renders the entire content tree from session state. The browser receives the whole inner HTML of #app — topbar, sidebar, scroller, and every visible row — and Idiomorph reconciles it against the live DOM. Stable ids (#scroller, #ds-window, #file-tree, #layout, #topbar, plus #f-<fid> per section and #file-row-<fid> per row) let the morph match in place; scroll position, focus, and one‑shot data-init survive across pushes.

Imperative actions — scroll to a file, scroll to the top, recenter the sidebar — can't be expressed as DOM changes; they have to call scrollTo. They ride inside the morph as a transient command element:

// first child of #app's inner morph, only when needed
<div id="cmd-42"
     data-signals='{"navEpoch":3}'
     data-init="window.__largediffJump?.(2007388)">
</div>

The id carries a monotonic counter (cmdSeq) that bumps on every push that needs to fire imperatives, so Idiomorph treats the element as new and Datastar re‑runs both plugins. data-init calls the scroll function directly — no signal gate, so a target pixel of 0 (back to top, cmd+Up) works the same as any other value. data-signals carries navEpoch back to the client so the next /view POST echoes the current epoch and the server can drop stale scroll events from the prior position.

A class of bugs disappeared with the third event.

The split protocol had at least four failure modes you could only see at the seams:

• State drift between fingerprints. Moving the active class from one sidebar row to another doesn't change the rendered HTML's byte length, so a length‑keyed fingerprint silently treated it as unchanged. The sidebar's morph got skipped, the highlight stuck to the old row, and the user blamed Datastar. With one fingerprint that includes activeFileId, this can't happen.
• The imperative‑signal‑can't‑be‑zero trap. A data-effect="$jumpToPx > 0" gate can't carry jumpToPx = 0 as a target. Back‑to‑top, cmd+Up, and any /jump to file 0 had to be special‑cased. With data-init firing on a fresh‑id element, there is no gate; the expression just runs.
• Sequencing across events. Diff morph → signals → sidebar morph means the client sees three intermediate DOM states per push. Idiomorph applies each event in its own task, and the browser can paint between them. Users sometimes saw the sidebar update before the diff caught up, or scroll happen before the target section was mounted. One morph applies the entire next state atomically.
• Routing every new feature. Adding a new piece of state — "show file count," "swap a chrome mode," "mark a file reviewed" — meant deciding which event carries it. Sometimes the answer was "two of them." Now the answer is always: change the session state, the next morph carries the difference.

The UI is a pure function of session state. There is no way to make the rendered tree disagree with the server's model, because there is nowhere else for it to come from. Immediate‑mode rendering with a single projection — same pattern a game loop uses to redraw the frame from world state, retargeted at a DOM.

The trade-off, and why it stopped hurting.

The cost is real: every push ships the entire #app inner instead of just the slice that changed. The wire eats it without complaint — a warm brotli encoder per session compresses against the prior frame's dictionary, so the topbar, the sticky chrome, and the unchanged sidebar rows cost almost nothing per push. The topbar's "wire" chip shows the running ratio; on a typical session it sits around 94 % saved.

The harder cost was on the client side. We measured it. It wasn't the wire; it was the browser's style work on the ~3,000 token spans of any newly‑mounted file section. Re‑enabling content-visibility: auto on .file-section deferred the per‑span style work to the moment a section enters the viewport, and the scroll‑time style recalc dropped from ~95 ms per push to not flagged by the trace at all. The forced reflow inside Datastar's morph went the same way — 395 ms aggregated over five scrolls is now zero in Chrome's performance insights.

Larger payload, smaller mental model, equal latency. The architecture trades a thing the server is good at (rendering bytes) for a thing programmers are bad at (keeping three concurrent views of state in sync).

Tokens in the DOM

Tokens render where the spec wants them: in the DOM.

The first version of largediff tried to be clever about syntax highlighting. Per‑token <span>s are the classic place a diff view collapses, so we kept row text as a plain text node and used the CSS Custom Highlight API instead. The server shipped [fileId, lineIdx, startCol, endCol] tuples; the client built one Highlight per kind and registered it with CSS.highlights.set("ds-keyword", …). Six kinds, ~1,500 ranges, no <span> allocation. In Blink it ran in about two milliseconds.

In WebKit it stalled the paint pipeline for 200–800 ms after every jump.

The engines implement the API differently. Reading the WebKit source, Highlight::repaintRange() walks each node a range intersects and calls repaint() per renderer; Blink batches the same work in its PrePaint pass. With ~1,500 ranges per push, the per-renderer walk adds up. It's a reasonable difference between two engines; it's just not a difference we can paper over from userland.

Looking at production: Monaco, CodeMirror 6, GitHub's PR diff view, Sourcegraph, Zed — none use CSS.highlights for syntax tokens. They all use per‑token spans (or, in Zed's case, GPU glyphs). The API is designed for cross‑token annotations like find-in-page hits and blame ribbons, not for token coloring at scale. We were choosing a path that nobody who renders code at scale chooses.

So now we render what everyone else renders. The morph payload carries the spans inline:

Class names compress beautifully under brotli (the dictionary picks them up on the second push), the wire cost ends up similar to the CSS-Highlight version, and both engines paint the page the same way because we're letting the browser do what it already does well: text rendering. The 200–800 ms post-jump stall is gone.