Cheng Lou spent years building the tools that power modern web development—React's animation libraries, ReScript's type system, and parts of Midjourney's interface architecture. Last Friday, he released something that might eclipse all of it: a 15-kilobyte library that solves a performance problem the web has carried since 1991.
The problem is deceptively simple. Every time a developer needs to know where text will appear on a webpage—how tall a paragraph will be, where a line will break—the browser recalculates the geometry of potentially the entire page. This operation, called layout reflow, is the reason your Twitter feed stutters when loading new posts, why chat interfaces freeze during long AI responses, and why responsive designs still feel clunky on mobile devices despite a decade of optimization efforts.
Lou's library, Pretext, bypasses the browser's Document Object Model entirely. It calculates text layout using pure mathematics, achieving speeds 300 to 600 times faster than standard browser APIs. Within 48 hours of release, it accumulated 14,000 GitHub stars and 19 million views on X. More importantly, developers immediately began building things that were previously impossible: text that flows around animated objects at 60 frames per second, magazine layouts that reflow instantly as you drag elements across the page, and chat bubbles that calculate their optimal width without causing the page to stutter.
Why measuring text breaks the web
The web's text rendering system was designed for academic papers, not interactive applications. When Tim Berners-Lee created HTML at CERN, the goal was to share static physics documents. The browser would receive a document, calculate its layout once, and display it. User interaction meant clicking a link to load an entirely new document.
Modern web applications violate this assumption constantly. A single scroll through a social media feed might trigger hundreds of layout calculations as new content loads, images appear, and ads resize themselves. Each calculation forces the browser to pause JavaScript execution, recalculate the position of every affected element, and repaint the screen. On a desktop with a powerful GPU, this might cause a barely perceptible stutter. On a mobile device running a complex web application, it can drain battery life and make interfaces feel sluggish.
The standard workaround has been to avoid measuring things. Developers use fixed heights, estimate dimensions, or accept janky behavior. This is why most chat applications don't smoothly animate new messages appearing—calculating the height of each message in real-time would cause unacceptable performance degradation. It's why virtualized lists (the technology that lets you scroll through thousands of items efficiently) struggle with variable-height content. The browser simply cannot tell you how tall something will be without doing expensive work.
Lou's approach treats the browser's Canvas API—originally designed for drawing graphics—as a measurement oracle. Canvas can report font metrics without triggering layout reflow because it operates outside the DOM. Pretext uses these metrics to build a mathematical model of how text will flow, then applies pure arithmetic to predict line breaks, heights, and positions. The result is a function that can answer "how tall will this text be at this width?" in microseconds rather than milliseconds.
The AI development method behind the breakthrough
Lou described the development process as "crawling through depths of hell," and the technical challenge explains why. Text rendering is one of the most complex and inconsistent parts of web browsers. Different engines handle kerning differently. Line-breaking algorithms vary between Chrome, Safari, and Firefox. Unicode bidirectional text—mixing English and Arabic in the same sentence—follows arcane rules that even experienced developers rarely understand fully.
To achieve pixel-perfect accuracy, Lou used what he calls "AI-friendly iteration." He fed large text corpora—including the complete text of The Great Gatsby and multilingual datasets—to models like Claude and OpenAI's Codex, asking them to generate TypeScript code that would match actual browser rendering. The models would produce layout logic, Lou would test it against real browser output, identify discrepancies, and feed the errors back to the models for refinement.
This approach represents a shift in how fundamental infrastructure gets built. Traditionally, a library like Pretext would require either years of manual development or a heavy WebAssembly binary that bundles an entire font-parsing engine. Lou achieved comparable accuracy with a 15KB JavaScript library by using AI models as a compression mechanism—they encoded decades of browser quirks and typographic knowledge into compact, maintainable code.
The implications extend beyond this single project. If one engineer using AI coding tools can solve a 30-year-old architectural problem in the time it takes most teams to ship a feature update, we're entering a period where small teams can build infrastructure that previously required industry-wide standardization efforts.
What becomes possible when text is fast
The weekend after Pretext launched, developers built a dragon that flies through paragraphs while letters melt and scatter around its animated form. Someone created an app that makes text fall off your phone screen like physical objects when you tilt the device. Another developer built a split-screen interface that lets you watch the new Project Hail Mary film while reading the book simultaneously, with the text responding dynamically to the video playback.
Critics immediately pointed out that many of these demos sacrifice readability for spectacle. They're missing the point. These experiments are developers testing the boundaries of a new capability, the same way early iPhone apps included gratuitous skeuomorphic animations and physics effects. The flashy demos will fade, but the underlying capability—being able to treat text as a fully dynamic, interactive medium—will reshape how interfaces work.
More practical applications are already emerging. One developer built a custom font resizer and letter-spacing optimizer for users with dyslexia, allowing real-time adjustment without page reflow. Another implemented the Knuth-Plass paragraph justification algorithm, which analyzes entire paragraphs to minimize awkward spacing—a technique used in high-end print typography but previously too expensive for web use. A third created a live newspaper generator that uses AI to analyze images and social media posts, then instantly lays out a formatted front page.
The performance characteristics enable entirely new interface patterns. Virtualized lists—the technology that powers infinite scrolling in applications like Twitter and Gmail—have always struggled with variable-height content because calculating heights is expensive. Pretext reduces height calculation to simple arithmetic, making it feasible to virtualize feeds with complex, multiline text content. One demo showed a masonry grid of hundreds of thousands of text boxes, each with different content and dimensions, scrolling smoothly at 60 frames per second.
The thick client debate and what it means for web architecture
Not everyone celebrated the release. A vocal contingent of developers argued that Pretext represents a dangerous trend toward "thick client" applications that abandon the web's core principles. By moving layout calculation from the browser into JavaScript, Pretext shifts responsibility for accessibility, internationalization, and standards compliance from browser vendors to individual developers.
This criticism has merit. The browser's layout engine handles thousands of edge cases automatically: right-to-left text, screen reader compatibility, font fallbacks, and platform-specific rendering differences. When you bypass the DOM, you become responsible for all of it. A poorly implemented Pretext-based interface could easily break accessibility features or render incorrectly for users with non-Latin scripts.
Lou's response reframes the debate historically. He points to iOS, which evolved from PostScript—a static format designed for printers—into a dynamic, scriptable platform. The web, by contrast, has remained conceptually tied to its document origins, layering scripting capabilities on top of a static core until the complexity became unsustainable. Pretext treats layout as an interpreter—a set of functions developers can manipulate—rather than a black-box format managed by the browser.
This philosophical shift has practical consequences for organizations. Adopting Pretext means accepting responsibility for behavior that browsers previously handled automatically. It requires developers who understand typography, internationalization, and accessibility at a deeper level than typical web development demands. For companies building standard content websites, this trade-off makes little sense. For teams building complex, interactive applications—AI chat interfaces, real-time collaboration tools, data visualization dashboards—the performance gains justify the additional complexity.
Strategic implications for product teams
The immediate question for engineering leaders is whether to adopt Pretext now or wait for the ecosystem to mature. The answer depends on what you're building and who you're building it for.
Teams working on generative AI interfaces should adopt immediately. The defining characteristic of AI-powered applications is unpredictability—you don't know how long a response will be or how it will be structured until the model generates it. Traditional web layouts handle this poorly, causing visible reflows and stuttering as content streams in. Pretext allows you to calculate layout synchronously as tokens arrive, creating smooth, responsive interfaces that feel as fast as the underlying models.
Similarly, applications with high-frequency data updates—trading dashboards, monitoring tools, real-time collaboration interfaces—benefit enormously from eliminating layout reflow as a bottleneck. If your application currently throttles updates or batches layout changes to maintain acceptable performance, Pretext removes those constraints.
For content-focused websites and traditional web applications, the calculus is different. The performance gains matter less when layout changes are infrequent, and the risks—accessibility issues, maintenance burden, browser compatibility—outweigh the benefits. These teams should monitor the ecosystem but avoid premature adoption.
The broader strategic insight is that AI-assisted development has moved beyond generating boilerplate code. Lou used AI models to solve a fundamental architectural problem that the web standards community has struggled with for decades. This suggests a future where small, high-leverage teams can build bespoke infrastructure that bypasses platform constraints, effectively decoupling product innovation from the slow cycle of industry-wide standardization.
Organizations that recognize this shift early will have an advantage. The ability to treat core platform capabilities—layout, rendering, state management—as malleable primitives rather than fixed constraints opens up design possibilities that competitors relying on standard approaches cannot match. Pretext is the first major example of this dynamic, but it won't be the last. The web is finally becoming programmable in the way native platforms have been for years, and the teams that embrace this flexibility will define what interfaces look like in the AI era.
