Why Measuring Text Nearly Broke the Web—And How One Dev Fixed It

There's a particular flavor of engineering problem that exists in plain sight for decades, causing daily frustration, yet somehow manages to avoid being treated as solvable. Text measurement in browsers is one of those problems.

Cheng Lou, former React core team member and current Midjourney engineer, just released Pretext—a TypeScript library that measures text without asking the browser to do it. This sounds technical and niche until you realize what it means: we've been building around a fundamental performance bottleneck since the browser was invented, and now we might not have to.

The Problem Nobody Wanted to Solve

Every time a browser needs to figure out how tall a paragraph is or where to break a line, it triggers a layout reflow. This operation recalculates the position and geometry of potentially every element on the page. It's computationally expensive—one of the most expensive things a browser does—and it happens constantly in any text-heavy interface.

Want to build a virtualized list that only renders visible messages? You need to know the height of each message before you can calculate which ones are on screen. Want a masonry layout with text blocks of varying sizes? Same problem. The traditional options are: render everything and measure it (slow), guess the dimensions (wrong), or architect around the limitation entirely (what most developers do).

"Ever since Al Gore invented the internet, rendering dynamic text has had a performance trade-off," the Fireship video explains. "This makes it unreasonably difficult to build any sort of text heavy UI like a virtualized list or a masonry layout."

This isn't a new problem. It's been present since the Clinton administration designed the text rendering pipeline. But treating it as unfixable became industry consensus.

Bypassing the Browser Entirely

Lou's solution is conceptually straightforward: don't ask the browser. Use the Canvas API to get pixel widths for text strings—Canvas lives outside the DOM, so no reflow. Then write a custom algorithm that accounts for how every major browser across every language handles line breaks, and calculate height yourself.

The conceptual simplicity masks brutal implementation complexity. Lou describes using AI models in what he calls "a recursive hellscape"—having them write line break logic, test it against real browsers, compare results, iterate for weeks. The goal was an algorithm that matched browser behavior without triggering browser calculation.

The result is an API that feels too simple for what it does:

// Prepare text (breaks into segments, caches widths)
const prepared = pretext.prepareWithSegments(text);

// Get dimensions without touching the DOM
const { height, lineCount } = layout(prepared);

No DOM access. No reflow. Just measurements.

What This Actually Enables

The Fireship demo shows text-based video rendering—drawing video frames using ASCII characters where brightness determines which letters appear. It's a technical flex, but the underlying capability is what matters: knowing exactly where every character lands before rendering anything.

That capability unlocks interfaces that were previously too expensive to build. Virtualized text-heavy UIs without the measurement overhead. Dynamic layouts that respond to content without recalculating everything. Text editors that can handle massive documents because they don't need to render offscreen content to know its dimensions.

The question isn't whether Pretext solves a real problem—it obviously does. The question is whether the browser's text measurement monopoly was actually necessary, or just something we accepted because challenging it seemed unreasonable.

The Security Angle Nobody's Discussing

From a security perspective, any library that reimplements core browser functionality deserves scrutiny. Browsers have spent decades hardening text rendering against Unicode exploits, bidirectional text attacks, and rendering inconsistencies that could be weaponized.

Lou's approach of using AI to match browser behavior across languages and systems is clever engineering, but it's also a potential attack surface. If Pretext's line break algorithm diverges from browser behavior in edge cases—especially with complex scripts or unusual Unicode sequences—you could end up with text that measures one way in Pretext but renders differently in the browser.

That divergence could matter for security-critical applications. Imagine a moderation system that uses Pretext to determine if a message fits within allowed bounds, but a browser renders it differently, exposing hidden content. Or a URL display that Pretext measures as safe but a browser interprets as malicious due to bidirectional text override characters.

To be clear: there's no evidence Pretext has these vulnerabilities. Lou's testing methodology specifically targeted browser matching. But introducing a parallel text measurement system means introducing parallel text measurement bugs. The browser's system has had three decades of exploitation attempts to refine it.

Developers adopting Pretext should understand they're trading a different set of risks—known browser performance costs for unknown algorithmic divergence risks. For many applications, that's a reasonable trade. For security-sensitive ones, it requires careful threat modeling.

What Success Looks Like

If Pretext succeeds, it won't be because every developer immediately rewrites their text handling code. It'll be because it proves the browser doesn't own foundational UI operations by divine right.

That proof-of-concept matters more than the specific implementation. Lou's library demonstrates that problems we've treated as unsolvable constraints might just be engineering challenges nobody funded. The text measurement problem existed in public for 30 years before someone with Lou's specific combination of skills, institutional knowledge, and apparent stubbornness decided to solve it.

The question now is: what other assumed constraints are just unquestioned technical debt?

Rachel 'Rach' Kovacs is Buzzrag's cybersecurity and privacy correspondent.