7 min read
A JavaScript library built by a Midjourney engineer promises to radically speed up text layout in the browser. 6,800 GitHub stars in a matter of days, Hacker News buzzing, heated debates on X about whether CSS has finally met its match. The demos look like magic. But look closer and you find a story built on browser legacy quirks, clever hacks, and the perennial question: when does an abstraction become the solution — and when does it become the problem?
The essentials
- What: Pretext is an MIT-licensed JavaScript library that computes text layout in the browser without triggering DOM reflows — roughly 500 times faster than DOM-based approaches, according to its author, who himself calls the comparison “unfair”
- Who: Cheng Lou, engineer at Midjourney and React contributor, creator of react-motion (over 21,700 GitHub stars)
- How: A two-phase approach — a single measurement pass via Canvas (~19 ms for 500 texts), followed by pure arithmetic in the hot path (~0.09 ms)
- For whom: High-performance UIs such as messaging interfaces, editorial tools, or virtual lists — not standard websites
- Context: A technically sound approach backed by a serious developer, but the viral hype far outpaces the project’s current level of maturity
Why the Internet Lost Its Mind
There are moments in the frontend world when someone demonstrates something that, in theory, simply should not be possible. Text flowing in real time around arbitrary shapes. Chat bubbles adjusting pixel by pixel to their content. Magazine layouts responding at 120 frames per second. In the browser. No hacks, no workarounds, no bringing the page to its knees.
Cheng Lou demonstrated exactly that last week. “I have traversed the depths of hell to bring you what I consider one of the most important foundations of UI engineering for years to come,” he wrote on X. Understatement is not his strong suit. But the demos deliver on their promises — at least at first glance.
Pretext is the library in question. Over 6,800 GitHub stars in just a few days. On Hacker News, a debate opened under the title “The future of text layout is not CSS.” The React community reacted as if a favourite band had just dropped a new album.
Part of that reaction comes down to who sent it. Cheng Lou is no stranger to the frontend world. At Meta, he worked on React, ReasonML, and Messenger. His side project react-motion (more than 21,700 GitHub stars) is one of the most widely used animation libraries in the React ecosystem. Now at Midjourney, he is building the frontend architecture: Bun stack, vanilla React, no framework. Five full-time developers serving millions of users. When someone of that calibre says the browser is broken, people listen.
The Thirty-Year Problem Nobody Noticed
To understand why Pretext exists, you need to grasp what the browser actually does when it renders text. Short version: far too much.
Every time the browser needs to calculate the height of a text block or determine where a line should break, it triggers a layout reflow. It measures characters, calculates spacing, breaks lines, checks overflow rules, and updates the layout of every surrounding element. This is one of the most expensive operations a browser performs. On a static website, that’s fine. On dynamic interfaces – messaging apps, editors, animated layouts, virtual lists with thousands of entries – it becomes a bottleneck.
The catch? Most developers never notice the problem. Their site works, after all. Text renders, lines break, everything looks fine. It’s only when you try to dynamically lay out hundreds of text blocks simultaneously – a messaging app, a whiteboard tool, a magazine layout editor – that you hit the wall. And that wall has been there since Netscape Navigator rendered its first HTML layout in 1994.
How Pretext Outsmarts the Browser
The solution Pretext proposes is conceptually elegant and technically demanding.
Phase 1 – prepare(): Text is normalized, split into segments, then measured via the browser’s Canvas API. Not through the DOM, but through the low-level font engine the browser already carries. Results are stored in a cache. This takes around 19 milliseconds once for 500 text blocks. Pay once, use as many times as you like.
Phase 2 – layout(): From this point, Pretext does nothing but arithmetic on the stored widths. Zero DOM contact. Where does the line break? What will the paragraph height be? Does the text fit in this box? All of these questions are resolved by math, not by the browser’s layout engine. 0,09 milliseconds for 500 texts.
This unlocks capabilities that are impossible with CSS alone: text that flows dynamically around arbitrary shapes; containers that shrink-wrap precisely to the minimum width needed for a given number of lines; magazine-style layouts with variable column widths – all at 120 frames per second.
One detail that will make frontend developers do a double-take: according to Cheng Lou, the engine was largely developed with the help of Claude Code and Codex. These AI tools compare their results against the ground truth provided by the browser, iterate on edge cases, and optimize the layout algorithm. It’s a fascinating example of AI-assisted engineering — when the task is clearly defined and the feedback signal is explicit.
The demos: “wow” effect with footnotes
The official demo page showcases seven examples: from accordion layouts to chat bubbles with minimal whitespace, including an editorial editor demo with animated multi-column layout, pull quotes, and live reflow. Community demos reproducing magazine layouts and Masonry grids round out the collection.
At first glance, the demos feel like something that simply shouldn’t be possible in a browser. Text flows fluidly around obstacles, containers adapt in real time, layouts respond without any perceptible delay. Then come the everyday use cases: textareas that auto-expand, vertical centering of multi-line text, and even variable typographic ASCII art as a proof of concept.
And then you click on the Hacker News thread. And the footnotes begin.
What the hype glosses over
“~500x, but it’s an unfair comparison.”
Cheng Lou on his own benchmark, X, March 2026
The fact that the developer himself calls his benchmark “unfair” deserves some credit. The roughly 500x speedup in the hot path compares a cached computation path against a full initial measurement via getBoundingClientRect(). It’s a bit like saying “my car is 500 times faster than yours” — but only if you don’t count the time it takes to fill the tank. The initial prepare step costs 19 milliseconds. For most websites, the difference is negligible, since they don’t trigger hundreds of reflows per frame.
Demo quality at launch: Several developers noted that the demo page itself had rendering issues. Text was clipped (overflow: hidden), and according to one Hacker News comment, the page was “totally and completely broken” on mobile. One developer put it bluntly: “The library that wants to fix the web has a broken website.” Most of these issues have since been resolved.
CSS could already do this: Some of the layouts on display — text wrapping around shapes, exclusion zones, regions — were planned as CSS features. CSS Exclusions and CSS Regions exist as specifications. They were never widely implemented because browser vendors prioritized other things. Pretext isn’t solving a CSS problem, then — it’s solving a browser commitment problem. That’s an important distinction.
Maturity level: Pretext is an early-stage Open-Source-Projekt. The author honestly documents its limitations: using system-ui as the font can lead to imprecise measurements on macOS. Very narrow containers cause mid-word line breaks. Server-side rendering isn’t finalized yet. Anyone deploying Pretext in production today is an early adopter — with all that entails.
Who Pretext is actually relevant for
The library solves a real problem – but a specific one. Pretext becomes relevant wherever many text blocks need to be laid out dynamically and simultaneously:
- Messaging interfaces: Chat applications that virtualize thousands of message bubbles and need to calculate their height in advance
- Editorial tools: Layout editors for magazines, newsletters, or presentations that flow text around images in real time
- Canvas-based interfaces: Whiteboard tools like Figma or Miro that render text outside the DOM
- Virtual lists: Any application that displays hundreds or thousands of text blocks and needs to know their dimensions before they appear in the visible area (viewport)
For DACH companies building their own SaaS products with heavily text-driven interfaces, it is worth tracking how the project matures. For a corporate website, a blog, or a landing page, Pretext offers no measurable benefit. And that is perfectly fine. Not every library needs to save the world. Sometimes, solving a hard problem elegantly for the right audience is more than enough.
Putting it in perspective: between genius and hype
Pretext is neither a scam nor an empty promise. The technical core – eliminating DOM measurements from the layout hot path and replacing them with cached arithmetic calculations – is a valid approach that makes a genuine difference for certain use cases. The fact that Cheng Lou himself describes his benchmark as “unfair” and clearly documents the project’s limitations sets him pleasantly apart from the usual developer influencers who present a new framework as the next revolution every single week.
The truth, as so often, lies somewhere in the middle. No, “every website you’ve ever used” is not broken. That viral claim is clickbait, almost certainly chosen deliberately. But the underlying problem is real: browser layout is too slow for certain use cases, and CSS has promised features that never materialized. Pretext fills that gap – with elegance, performance, and clearly defined boundaries.
What remains: an impressive technical feat from a developer who knows exactly what they are doing. A library that, in a year’s time, will either be an indispensable component of the frontend toolkit – or a brilliant prototype gathering dust on the “Awesome JavaScript” list. Either outcome would be fully deserved.
Frequently Asked Questions
What exactly is Pretext?
An MIT-licensed JavaScript/TypeScript library that calculates text layout in the browser without any DOM operations. It measures text once via the Canvas API, then computes line breaks, heights, and positions using purely mathematical methods. Developed by Cheng Lou (Midjourney, formerly at Meta).
Is Pretext really 500 times faster than CSS?
In the hot path, according to the developer, roughly 500 times faster: 0.09 ms for 500 text blocks versus DOM measurements via getBoundingClientRect(). Cheng Lou himself calls this comparison “unfair,” since the one-time initial measurement (~19 ms) is not included. For standard websites, the difference is irrelevant.
Does Pretext replace CSS?
No. Pretext does not replace the browser’s rendering engine. It uses the browser’s font engine as a foundation but bypasses the DOM layout process for text calculation. CSS remains responsible for styling, colors, spacing, and all other aspects of layout.
Do I need Pretext for my website?
Probably not. Pretext is relevant for messaging applications, editorial tools, Canvas-based interfaces, and virtual lists. It offers no advantage for blogs, corporate websites, or e-commerce. The developer acknowledges this himself.
How mature is the project?
Over 6,800 GitHub stars, but the project is still in active development. Server-side rendering is absent, and the demo page had rendering issues at launch. Using system-ui as the font can lead to imprecise measurements on macOS. For production use, maturity should be monitored carefully.
Was Pretext developed with AI assistance?
Yes. According to Cheng Lou, the engine was largely developed using Claude Code and Codex. These AI tools compare their results against the ground truth provided by the browser and iterate on edge cases. It’s a compelling example of AI-assisted library development, with a clearly defined feedback signal.
Editor’s Picks
More articles from the MBF Media network
Digital Chiefs: Mittelstand Digitalization 2026 – The Honest Status Report
SecurityToday: Copilot as a Security Risk
MyBusinessFuture: AI “Made in Germany” – 935 Startups
Image source: Pexels / Rashed Paykary (px:31343632)
