7 min Reading Time
A JavaScript library built by a Midjourney engineer promises to radically accelerate text layout in the browser. 6,800 GitHub stars in just days, Hacker News ablaze, debates on X about whether CSS is obsolete. The demos feel like magic. But look closer – and you’ll find a story about browser legacy baggage, ingenious hacks, and the eternal question: When does an abstraction become the solution – and when does it become the problem?
TL;DR
- What: Pretext is an MIT-licensed JavaScript library that computes text layout in the browser without DOM reflows – reportedly ~500× faster than DOM-based layout (a comparison the author himself calls “unfair”)
- Who: Cheng Lou, Midjourney engineer and React contributor; creator of react-motion (21,700+ stars)
- How: Two-phase approach – initial measurement via Canvas (~19 ms for 500 texts), then pure arithmetic in the hot path (~0.09 ms)
- For whom: High-performance UIs like chat interfaces, editorial tools, and virtualized lists – not standard websites
- Context: A technically sound approach from a credible developer – but the viral hype far exceeds the project’s current maturity
Why the Internet Lost Its Mind
There are moments in frontend development when someone demonstrates something that shouldn’t be possible. Text flowing in real time around arbitrary shapes. Chat bubbles adapting pixel-perfectly to their content. Magazine layouts responding at 120 fps. In the browser. Without hacks, without workarounds – and without grinding the page to a halt.
Cheng Lou demonstrated exactly that last week. “I’ve been through the depths of hell to bring you what I believe to be one of the more important UI engineering foundations for years to come,” he wrote on X. Understatement isn’t his strong suit. But the demos deliver on the promise – at least at first glance.
Pretext is the library in question. Over 6,800 GitHub stars in just days. On Hacker News, debate erupted under the headline “The future of text layout is not CSS.” The React community reacted like it was hearing a new album from its favorite band.
That reaction also stems from the messenger. Cheng Lou is no unknown in the frontend world. At Meta, he worked on React, ReasonML, and Messenger. His side project react-motion (21,700+ GitHub stars) remains one of the most widely used animation libraries in the React ecosystem. Today, he architects the frontend at Midjourney: Bun-stack, vanilla React, no framework. Five full-time developers serving millions of users. When this person says the browser is broken, people listen.
The 30-Year-Old Problem No One Noticed
To understand why Pretext exists, you need to grasp what browsers actually do when rendering text. The short version: far too much.
Every time the browser must calculate how tall a text block is – or where a line wraps – it triggers a layout reflow. It measures glyphs, computes spacing, wraps lines, checks overflow rules, and updates the layout of all surrounding elements. This is among the most expensive operations in the browser. On static sites, it doesn’t matter. But in dynamic interfaces – chat apps, editors, animated layouts, virtualized lists with thousands of entries – it becomes a bottleneck.
The insidious part? Most developers never notice. Their sites work. Text appears. Lines wrap. Everything looks fine. Only when you try to dynamically lay out hundreds of text blocks simultaneously – a chat app, a whiteboard tool, a magazine layout editor – do you hit the wall. And that wall has stood since Netscape Navigator rendered its first HTML layout in 1994.
How Pretext Tricks the Browser
Pretext’s solution is conceptually elegant – and technically demanding.
Phase 1 – prepare(): Text is normalized, split into segments, and measured using the browser’s Canvas API – not the DOM, but the low-level font engine the browser already ships with. Results are cached. This one-time cost takes roughly 19 milliseconds for 500 text blocks. Pay once, use infinitely.
Phase 2 – layout(): From here on, Pretext performs arithmetic only – using cached width values. No DOM interaction. Where does the line wrap? How tall is the paragraph? Does the text fit in this box? All answers derived from math – not browser layout. 0.09 milliseconds for 500 texts.
This enables things CSS simply can’t do: text dynamically flowing around arbitrary shapes; containers shrinking precisely to the narrowest width needed for a given number of lines (“shrink-wrap”); magazine-style layouts with variable column widths – all at 120 frames per second.
One detail likely to make frontend developers sit up straight: According to Cheng Lou, the engine was developed significantly with the help of Claude Code and Codex. These AI tools benchmark against the browser’s ground truth, iterate over edge cases, and optimize the layout algorithm. It’s a fascinating example of AI-assisted engineering – when the task is well-defined and the feedback signal unambiguous.
The Demos: Wow Factor – with Footnotes
The official demo site features seven showcases: from accordion layouts and chat bubbles with minimal whitespace to an editorial engine demo with animated multi-column layouts, pull quotes, and live reflow. Community demos add magazine layouts and Masonry grids.
At first glance, the demos feel like something impossible in the browser. Text flows smoothly around obstacles. Containers adapt in real time. Layouts respond without visible lag. Then there are everyday pain points: auto-growing textareas, multi-line text centering – even variable-font ASCII art as a proof of concept.
And then you click through to the Hacker News discussion. And the footnotes begin.
What the Hype Leaves Out
“~500x, but it’s an unfair comparison.”
Cheng Lou on his own benchmark, X, March 2026
That the developer himself labels his own benchmark “unfair” deserves respect. The ~500× speedup in the hot path compares a cached computation path against a full initial measurement using getBoundingClientRect(). It’s like saying “my car is 500× faster than yours” – but only if you ignore refueling time. The initial measurement (prepare) costs 19 milliseconds. For most websites, the difference is irrelevant – because they don’t trigger hundreds of reflows per frame.
Demo quality at launch: Several developers noted rendering issues on the demo site itself. Text was clipped (overflow: hidden), and according to one HN comment, the site was “fully and completely broken” on mobile devices. One developer dryly remarked: “The library that aims to fix the web has a broken website.” Most of these issues have since been fixed.
CSS could have done this – technically: Some showcased layouts – text wrapping around shapes, exclusion zones, regions – were planned as CSS features. CSS Exclusions and CSS Regions exist as specifications. They were never broadly implemented because browser vendors prioritized differently. So Pretext doesn’t solve a CSS problem – it solves a browser commitment problem. That’s a crucial distinction.
Maturity level: Pretext is an early-stage open-source project. The author honestly documents its limitations: system-ui fonts may yield inaccurate measurements on macOS. Very narrow containers break words mid-word. Server-side rendering isn’t ready yet. Anyone deploying Pretext in production today is an early adopter – with all the associated risks.
Who Actually Benefits from Pretext?
The library solves a real problem – but a specific one. Pretext matters where many text blocks must be laid out dynamically, simultaneously:
- Chat interfaces: Messaging apps virtualizing thousands of message bubbles – and needing to pre-calculate their heights
- Editorial tools: Layout editors for magazines, newsletters, or presentations that flow text around images in real time
- Canvas-based UIs: Whiteboard tools like Figma or Miro, which render text outside the DOM
- Virtualized lists: Any application displaying hundreds or thousands of text blocks – and needing to know their dimensions before they appear in the viewport
For DACH companies building their own text-heavy SaaS products, tracking Pretext’s maturity makes sense. For a corporate website, a blog, or a landing page, Pretext delivers no measurable benefit. And that’s perfectly fine. Not every library needs to save the world. Sometimes, elegantly solving a hard problem for the right audience is enough.
Context: Between Genius and Hype
Pretext is neither a scam nor an empty promise. Its technical core – removing DOM measurements from the layout hot path and replacing them with cached arithmetic – is a valid approach that delivers tangible gains for certain use cases. That Cheng Lou openly labels his own benchmark “unfair” and transparently documents limitations sets him apart – refreshingly – from the usual dev influencers who declare the next framework revolutionary every week.
As so often, the truth lies in the middle. Not “every website you’ve ever used” is broken. That viral claim is clickbait – and likely intentional. But the underlying problem is real: browser layout is too slow for certain applications, and CSS promised features that never arrived. Pretext fills that gap – elegantly, performantly, and with clear boundaries.
What remains is an impressive technical achievement by a developer who knows exactly what he’s doing. A library that, in a year’s time, will either be a staple of the frontend toolkit – or fade into the “Awesome JavaScript” list as a brilliant experiment. Either outcome would be fitting.
Frequently Asked Questions
What exactly is Pretext?
An MIT-licensed JavaScript/TypeScript library that calculates text layout in the browser without DOM operations. It measures text once via the Canvas API, then computes line breaks, heights, and positioning purely through mathematics. Developed by Cheng Lou (Midjourney, former Meta).
Is Pretext really 500× faster than CSS?
In the hot path, yes – according to the developer: 0.09 ms for 500 text blocks versus DOM measurements via getBoundingClientRect(). Cheng Lou himself calls the comparison “unfair,” since it excludes the one-time initial measurement (~19 ms). For standard websites, the difference is irrelevant.
Does Pretext replace CSS?
No. Pretext does not replace the browser renderer. It leverages the browser’s font engine as a foundation – but bypasses the DOM layout process for text calculations. CSS remains responsible for styling, colors, spacing, and all other layout concerns.
Do I need this for my website?
Probably not. Pretext is relevant for chat apps, editorial tools, canvas-based UIs, and virtualized lists. It offers no advantage for blogs, corporate sites, or e-commerce platforms. The developer acknowledges this himself.
How mature is the project?
Over 6,800 GitHub stars – but still actively evolving. Server-side rendering is missing. The demo site had rendering issues at launch. system-ui fonts may cause inaccurate measurements on macOS. Production use requires careful monitoring of maturity.
Was Pretext developed with AI?
Yes. According to Cheng Lou, the engine was developed significantly using Claude Code and Codex. The AI tools benchmark against the browser’s ground truth and iterate over edge cases. It’s an intriguing example of AI-assisted library development – where the task is clearly defined and the feedback signal unambiguous.
Editor’s Reading Recommendations
More from the MBF Media Network
Digital Chiefs: Digitalization in German SMEs 2026 – The Honest Status Report
SecurityToday: Copilot as a Security Risk
MyBusinessFuture: AI Made in Germany – 935 Startups
Header Image Source: Pexels / Rashed Paykary (px:31343632)
