7 min read<\/p>\n
A JavaScript library built by a Midjourney<\/a> 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 \u2014 and when does it become the problem?<\/strong><\/p>\n 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.<\/p>\n 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 \u2014 at least at first glance.<\/p>\n “Every website you have ever used is broken. 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: fast, accurate text measurement in pure TypeScript.”<\/p>\n Pretext<\/a> 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.<\/p>\n 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<\/a>, and Messenger. His side project react-motion<\/a> (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<\/a>: Bun<\/a> 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.<\/p>\n To understand why Pretext exists, you need to grasp what the browser actually does when it renders text. Short version: far too much.<\/p>\n 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<\/em>. It measures characters, calculates spacing, breaks lines, checks overflow<\/em> 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.<\/p>\n 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.<\/p>\n The solution Pretext proposes is conceptually elegant and technically demanding.<\/p>\n Phase 1 – prepare():<\/strong> Text is normalized, split into segments, then measured via the browser’s Canvas API<\/a>. 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.<\/p>\n Phase 2 – layout():<\/strong> 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.<\/p>\n 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.<\/p>\n 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<\/em> provided by the browser, iterate on edge cases<\/em>, and optimize the layout algorithm. It’s a fascinating example of AI-assisted engineering \u2014 when the task is clearly defined and the feedback signal is explicit.<\/p>\n The official demo page showcases seven examples: from accordion layouts<\/a> to chat bubbles with minimal whitespace<\/a>, 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.<\/p>\n 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<\/a> as a proof of concept.<\/p>\n And then you click on the Hacker News thread. And the footnotes begin.<\/p>\n \n“~500x, but it’s an unfair comparison.” 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 Demo quality at launch:<\/strong> Several developers noted that the demo page itself had rendering issues. Text was clipped ( CSS could already do this:<\/strong> Some of the layouts on display \u2014 text wrapping around shapes, exclusion zones, regions \u2014 were planned as CSS features. CSS Exclusions<\/a> 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 \u2014 it’s solving a browser commitment problem. That’s an important distinction.<\/p>\n Maturity level:<\/strong> Pretext is an early-stage Open-Source-Projekt<\/a>. The author honestly documents its limitations: using 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:<\/p>\n 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.<\/p>\n Pretext is neither a scam nor an empty promise. The technical core – eliminating DOM measurements from the layout hot path<\/em> 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.<\/p>\n 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<\/em>, 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.<\/p>\n 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.<\/p>\n 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).<\/p>\n<\/details>\n In the hot path<\/em>, according to the developer, roughly 500 times faster: 0.09 ms for 500 text blocks versus DOM measurements via 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n 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 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<\/em> 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.<\/p>\n<\/details>\n Digital Chiefs: Mittelstand Digitalization 2026 – The Honest Status Report<\/a><\/p>\n SecurityToday: Copilot as a Security Risk<\/a><\/p>\n MyBusinessFuture: AI “Made in Germany” – 935 Startups<\/a><\/p>\nThe essentials<\/h2>\n
\n
Why the Internet Lost Its Mind<\/h2>\n
\nView the full thread on X \u2192<\/a>\n<\/div>\n<\/div>\nThe Thirty-Year Problem Nobody Noticed<\/h2>\n
How Pretext Outsmarts the Browser<\/h2>\n
The demos: “wow” effect with footnotes<\/h2>\n
What the hype glosses over<\/h2>\n
\nCheng Lou on his own benchmark, X, March 2026<\/cite>\n<\/p><\/blockquote>\ngetBoundingClientRect()<\/code>. It’s a bit like saying “my car is 500 times faster than yours” \u2014 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.<\/p>\noverflow: hidden<\/code>), 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.<\/p>\nsystem-ui<\/code> 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 \u2014 with all that entails.<\/p>\nWho Pretext is actually relevant for<\/h2>\n
\n
Putting it in perspective: between genius and hype<\/h2>\n
Frequently Asked Questions<\/h2>\n
What exactly is Pretext?<\/strong><\/summary>\n
Is Pretext really 500 times faster than CSS?<\/strong><\/summary>\n
getBoundingClientRect()<\/code>. 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.<\/p>\n<\/details>\nDoes Pretext replace CSS?<\/strong><\/summary>\n
Do I need Pretext for my website?<\/strong><\/summary>\n
How mature is the project?<\/strong><\/summary>\n
system-ui<\/code> as the font can lead to imprecise measurements on macOS. For production use, maturity should be monitored carefully.<\/p>\n<\/details>\nWas Pretext developed with AI assistance?<\/strong><\/summary>\n
Editor’s Picks<\/h2>\n
\n
More articles from the MBF Media network<\/h2>\n