Cheng Lou builds browser-reflow-free text measurement tool, bypassing CSS layout for AI application UIs
The Browser Still Thinks It’s 1996
There is a moment in every AI chat interface where the UI betrays itself. The tokens stream in, the text reflows, the layout stutters, and what should feel like a live conversation feels like a webpage loading. That is not a product problem. It is an architectural problem. And Cheng Lou just built the most direct answer to it I have seen.
Lou announced a pure TypeScript text measurement tool that does exactly what the name implies. It measures text. Without touching the DOM. Without triggering CSS layout. Without asking the browser anything at all.
The numbers he demoed are not incremental improvements. We are talking 0.05ms versus 30ms for a text measurement operation. Zero layout passes versus five hundred reflows per interaction. That is not a faster horse. That is a different animal entirely.
Why The Browser Is the Wrong Tool For This
The web was designed to render documents. HTML flows text, CSS styles it, the browser computes layout. That pipeline made sense for a page of articles and links. It makes much less sense for a chat interface that streams 50 tokens per second and needs to reflow dynamically around every one of them.
The problem is that CSS layout is the only official way to know how big text is on the web. Every time your code asks “how wide is this string rendered at 16px Inter?”, the browser has to run its layout engine to answer. That locks the main thread. At 60fps you have 16 milliseconds per frame total. One reflow can consume all of it. Five hundred reflows per interaction is not an edge case for an AI UI. It is Tuesday.
The industry has spent a decade building clever workarounds. React batches DOM writes with its virtual DOM. CSS containment limits which parts of the page reflow when something changes. FastDOM separates reads from writes to minimize forced layouts. Every one of these approaches accepts the same premise: the browser owns text measurement, so call it as rarely as possible.
Lou’s approach rejects the premise entirely.
Who Built This and Why That Matters
Lou’s background is worth paying attention to here. He worked on React at Facebook. He built ReasonML and ReScript. He worked on Messenger’s frontend. He now runs Midjourney’s entire UI stack on Bun. That is a career spent fighting browser rendering limitations at scale, across every major category of complex web application.
When someone with that history builds a tool that bypasses the browser’s layout engine for text measurement, the message is pretty clear. The workarounds are not sufficient. The abstraction needs to change.
Aakash Gupta put it cleanly on Twitter: “The person who helped build React, the most popular workaround for the browser’s layout engine, just said the workaround isn’t sufficient and built the replacement himself.”
I think that framing is exactly right.
What This Actually Unlocks For AI UIs
Every real-time AI interface running today has this problem. Streaming chat outputs, dynamic code blocks that resize as content arrives, sidebar layouts that adjust to model response length. All of it hits the same wall.
When text measurement costs 0.05ms instead of 30ms, things become possible that were not practical before. You can measure text on every token in a stream without budgeting for it. You can build layout engines that run entirely off the main thread. You can compute how a response will wrap before it renders. For interfaces built around AI output that is fundamentally unpredictable in length and structure, that is a real capability shift.
This also points toward something broader. The more AI generates UI content dynamically, the more the browser’s static-document assumptions become friction. Lou’s tool is one piece, but the direction it points matters as much as the tool itself.
Where This Is Heading
I do not think browser-native layout goes away. Most of the web is still documents, and CSS is fine for documents. But for application-grade interfaces built on top of AI, the rendering pipeline needs to be something you own, not something you work around.
Lou building this at Midjourney is not accidental context. Midjourney is a product where every output is different, every layout is dynamic, and performance directly affects whether the product feels alive or sluggish. The tool came from a real production problem, which means it was designed against real constraints, not theoretical ones.
The browser asked us to accept its limitations for thirty years. Some of us are done asking nicely.
Sources
#AIEngineering #FrontendDevelopment #WebPerformance #AIInterfaces #TypeScript
