The 15KB Library That Does What CSS Can't

There’s always been one unsolved problem in web development: you can’t know how tall text will be until the browser renders it.

That constraint sounds small, but it breaks everything from virtualized lists to chat UIs. And while there are workarounds, none of them have been clean. 

But Cheng Lou's Pretext — launched a little over 2 weeks ago — is the first time I've seen someone solve this problem well.

Uprooting the status quo

If you’ve ever built a virtualized list, you’ve run into this problem:

You need the height of each text block before rendering so you can position items correctly.

The standard approach is to read layout from the DOM (e.g., getBoundingClientRect() or offsetHeight), which forces a synchronous layout reflow. But do  this for 500 items and you've handed the browser a 30ms+ frame tax (and lost your 60fps target).

I've tried all the usual workarounds across my 25-year career: 

• Estimating heights using rough averages
• Pre-measuring in offscreen containers
• Batching DOM reads after writes
• Using overscan buffers in virtualized lists
• Accepting visual jank from late measurements

But none of these solve the underlying constraint.

Pretext takes a different approach entirely. It’s a ~15KB, zero-dependency TypeScript library that predicts text layout using precomputed font metrics and cached measurements — avoiding DOM reads, layout reflow, and rendering in the hot path.

The API splits into two phases:

• prepare() does the expensive work once, segmenting text and measuring word widths via an off-screen canvas.
• layout() runs the hot path using pure computation over cached data to determine line breaks and total height for a given container width.

According to project benchmarks (which are workload-dependent), the hot path can process 500 text blocks in ~0.09ms. That's orders of magnitude faster than traditional DOM-based measurement.

It's no wonder Pretext's GitHub repo has already hit 40K+ stars. Within 72 hours of its launch on March 27th, developers had built everything from a Knuth-Plass paragraph justification engine to a dyslexia-friendly font spacing optimizer. 

Having spent years working on products where browser API capabilities shaped what we could build, I pay attention to libraries that change the boundaries of what is practical. And Pretext really delivered for a true pain point in web development. 

But how it was built is even more impressive.

How Pretext was built  

Pretext was built using what Lou calls an "AI-friendly iteration method." Lou fed browser rendering outputs and benchmarks to Claude Code and OpenAI's Codex, pointed them at actual browser ground truth at every significant container width, and let them iterate for weeks.

The testing corpus included the full text of The Great Gatsby rendered across Chrome, Safari, and Firefox, plus lengthy documents in Thai, Chinese, Korean, Japanese, and Arabic from the project's corpora directory.

As blogger Simon Willison noted, this obsessive level of testing rigor is unusual for open source. 

And it didn't even take a whole team. It was just one person, armed with AI, who produced infrastructure-grade code that outperforms traditional DOM-based measurement approaches that have existed since the Netscape era.

So where does this actually matter in practice?

Where Pretext shines

Pretext is impressive in several practical scenarios where the browser’s render-first model becomes a bottleneck.

Virtualized lists with dynamic content

Tools like React Virtual and TanStack Virtual depend on estimating item heights ahead of time. Pretext replaces guesswork with accurate pre-render calculation (no reflow required).

Chat and messaging UIs

If you’ve ever built a chat interface, you know the pain: thousands of bubbles, each needing layout before render. Pretext makes height prediction deterministic instead of reactive.

Canvas and WebGL rendering

Editors like Figma or Excalidraw operate outside the DOM, which means text measurement is usually approximate or requires awkward round-trips. Pretext gives these tools a native-feeling layout engine in userland.

Capabilities CSS doesn’t expose

A feature like walkLineRanges() does something CSS simply cannot: compute the narrowest width that produces a fixed number of lines. That’s how you get perfectly shrink-wrapped chat bubbles without hacks like fit-content.

In short, anywhere you need to predict layout instead of reacting to it, Pretext can step in.

But like any tool that pushes beyond the platform, that power comes with trade-offs.

What's out of scope for Pretext

Pretext is intentionally narrow (that's both its strength and limitation). It targets a specific subset of CSS behavior: 

• white-space: normal
• word-break: normal
• overflow-wrap: break-word

Step outside that, and you’re back in approximation territory. And in real-world apps, teams hit those edge cases quickly.

There are also platform-specific quirks to be aware of. For example, the system-ui font is flagged as unreliable for measurement on macOS, and there's no server-side rendering support yet (which matters if you’re working in frameworks like Next.js or Remix). Font metrics must also remain stable, as dynamic font loading or fallback changes can affect measurement accuracy.

More importantly, moving layout logic out of the browser comes with hidden responsibility: the browser normally handles accessibility, font fallback, bidirectional text, and countless edge cases. Once you move that logic into a library, you inherit those concerns (whether you planned to or not).

Pretext certainly isn’t a replacement for CSS layout, but it is a surgical solution for a specific class of problems where the browser’s constraints become a performance liability.

The backwards compatibility question

Moving layout responsibility out of the browser and into userland is powerful, but it also raises a long-term question: Should this exist as a library at all?

The CSS Text Level 4 spec has been inching toward better intrinsic sizing primitives for years. If browsers eventually expose something like “calculate the minimum width for this text at N lines,” Pretext’s core use case starts to shrink.

But “eventually” is doing a lot of work here. While standards move at geological pace, applications don’t — and libraries like Pretext thrive in this gap.

It’s a familiar pattern. When the browser DOM was too slow, React worked around it. Years later, frameworks like Svelte proved you could compile away the abstraction entirely. The platform catches up (but usually long after developers have shipped their own solutions).

Pretext might not be a replacement for the platform, but it could be a preview of where the platform might eventually go.

What Pretext hints for web developers

Pretext is an early example of how a single developer with AI tools can produce foundational libraries faster than browser standards committees can spec them — and it won’t be the last.

If you are building virtualized feeds, chat interfaces, canvas-based editors, or any UI that needs to predict text height before rendering, it's worth checking Pretext out. The performance gain is real.

For engineers who want to understand the browser rendering pipeline that Pretext is working around — layout reflow, the CSSOM, paint and composite stages — Educative's web development fundamentals course covers this well. 

What is a browser limitation that you think AI tools could eventually solve?

Sumit Mehrotra has 25 years of experience in the tech industry, including senior product roles at Meta and Microsoft. He led Program Management for Microsoft Azure and has led product organizations at Databricks and Skytap. As VP of Product at Educative, he leads the development of interactive learning experiences for software engineers.

Grokking Weekly is published every Tuesday by Educative. Subscribe to get each edition in your feed.