7 min Reading Time<\/p>\n
A JavaScript library built by a Midjourney<\/a> 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\u2019ll 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?<\/strong><\/p>\n There are moments in frontend development when someone demonstrates something that shouldn\u2019t<\/em> 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.<\/p>\n Cheng Lou demonstrated exactly that last week. \u201cI\u2019ve 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,\u201d he wrote on X. Understatement isn\u2019t his strong suit. But the demos deliver on the promise – at least at first glance.<\/p>\n \u201cEvery website you’ve ever used is broken. 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: fast, accurate text measurement in pure TypeScript.\u201d<\/p>\n Pretext<\/a> is the library in question. Over 6,800 GitHub stars in just days. On Hacker News, debate erupted under the headline \u201cThe future of text layout is not CSS.\u201d The React community reacted like it was hearing a new album from its favorite band.<\/p>\n That reaction also stems from the messenger. Cheng Lou is no unknown in the frontend world. At Meta, he worked on React, ReasonML<\/a>, and Messenger. His side project react-motion<\/a> (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<\/a>-stack, vanilla React, no framework. Five full-time developers serving millions of users. When this person says the browser is broken, people listen.<\/p>\n To understand why Pretext exists, you need to grasp what browsers actually do when rendering text. The short version: far too much.<\/p>\n 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\u2019t matter. But in dynamic interfaces – chat apps, editors, animated layouts, virtualized lists with thousands of entries – it becomes a bottleneck.<\/p>\n The insidious part? Most developers never notice. Their sites work<\/em>. 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.<\/p>\n Pretext\u2019s solution is conceptually elegant – and technically demanding.<\/p>\n Phase 1 – prepare():<\/strong> Text is normalized, split into segments, and measured using the browser\u2019s Canvas API<\/a> – 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.<\/p>\n Phase 2 – layout():<\/strong> 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.<\/p>\n This enables things CSS simply can\u2019t do: text dynamically flowing around arbitrary shapes; containers shrinking precisely to the narrowest width needed for a given number of lines (\u201cshrink-wrap\u201d); magazine-style layouts with variable column widths – all at 120 frames per second.<\/p>\n 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\u2019s ground truth, iterate over edge cases, and optimize the layout algorithm. It\u2019s a fascinating example of AI-assisted engineering – when the task is well-defined and the feedback signal unambiguous.<\/p>\n The official demo site features seven showcases: from accordion layouts<\/a> and chat bubbles with minimal whitespace<\/a> to an editorial engine demo with animated multi-column layouts, pull quotes, and live reflow. Community demos add magazine layouts and Masonry grids.<\/p>\n 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<\/a> as a proof of concept.<\/p>\n And then you click through to the Hacker News discussion. And the footnotes begin.<\/p>\n \n\u201c~500x, but it’s an unfair comparison.\u201d That the developer himself labels his own benchmark \u201cunfair\u201d deserves respect. The ~500\u00d7 speedup in the hot path compares a cached computation path against a full initial measurement using Demo quality at launch:<\/strong> Several developers noted rendering issues on the demo site itself. Text was clipped ( CSS could have done this – technically:<\/strong> Some showcased layouts – text wrapping around shapes, exclusion zones, regions – were planned as CSS features. CSS Exclusions<\/a> and CSS Regions exist as specifications. They were never broadly implemented because browser vendors prioritized differently. So Pretext doesn\u2019t solve a CSS problem – it solves a browser commitment problem<\/em>. That\u2019s a crucial distinction.<\/p>\n Maturity level:<\/strong> Pretext is an early-stage open-source project<\/a>. The author honestly documents its limitations: The library solves a real problem – but a specific one. Pretext matters where many<\/em> text blocks must be laid out dynamically, simultaneously:<\/p>\n For DACH companies building their own text-heavy SaaS products, tracking Pretext\u2019s maturity makes sense. For a corporate website, a blog, or a landing page, Pretext delivers no measurable benefit. And that\u2019s perfectly fine. Not every library needs to save the world. Sometimes, elegantly solving a hard problem for the right audience is enough.<\/p>\n 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 \u201cunfair\u201d and transparently documents limitations sets him apart – refreshingly – from the usual dev influencers who declare the next framework revolutionary every week.<\/p>\n As so often, the truth lies in the middle. Not \u201cevery website you\u2019ve ever used\u201d 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.<\/p>\n What remains is an impressive technical achievement by a developer who knows exactly what he\u2019s doing. A library that, in a year\u2019s time, will either be a staple of the frontend toolkit – or fade into the \u201cAwesome JavaScript\u201d list as a brilliant experiment. Either outcome would be fitting.<\/p>\n An MIT-licensed JavaScript\/TypeScript library that calculates text layout in the browser without<\/em> 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).<\/p>\n<\/details>\n In the hot path, yes – according to the developer: 0.09 ms for 500 text blocks versus DOM measurements via No. Pretext does not replace the browser renderer. It leverages the browser\u2019s 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n Over 6,800 GitHub stars – but still actively evolving. Server-side rendering is missing. The demo site had rendering issues at launch. Yes. According to Cheng Lou, the engine was developed significantly using Claude Code and Codex. The AI tools benchmark against the browser\u2019s ground truth and iterate over edge cases. It\u2019s an intriguing example of AI-assisted library development – where the task is clearly defined and the feedback signal unambiguous.<\/p>\n<\/details>\n Digital Chiefs: Digitalization in German SMEs 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>\nTL;DR<\/h2>\n
\n
Why the Internet Lost Its Mind<\/h2>\n
\nView full thread on X \u2192<\/a>\n<\/div>\n<\/div>\nThe 30-Year-Old Problem No One Noticed<\/h2>\n
How Pretext Tricks the Browser<\/h2>\n
The Demos: Wow Factor – with Footnotes<\/h2>\n
What the Hype Leaves Out<\/h2>\n
\nCheng Lou on his own benchmark, X, March 2026<\/cite>\n<\/p><\/blockquote>\ngetBoundingClientRect()<\/code>. It\u2019s like saying \u201cmy car is 500\u00d7 faster than yours\u201d – but only if you ignore refueling time. The initial measurement (prepare<\/code>) costs 19 milliseconds. For most websites, the difference is irrelevant – because they don\u2019t trigger hundreds of reflows per frame.<\/p>\noverflow: hidden<\/code>), and according to one HN comment, the site was \u201cfully and completely broken\u201d on mobile devices. One developer dryly remarked: \u201cThe library that aims to fix the web has a broken website.\u201d Most of these issues have since been fixed.<\/p>\nsystem-ui<\/code> fonts may yield inaccurate measurements on macOS. Very narrow containers break words mid-word. Server-side rendering isn\u2019t ready yet. Anyone deploying Pretext in production today is an early adopter – with all the associated risks.<\/p>\nWho Actually Benefits from Pretext?<\/h2>\n
\n
Context: Between Genius and Hype<\/h2>\n
Frequently Asked Questions<\/h2>\n
What exactly is Pretext?<\/strong><\/summary>\n
Is Pretext really 500\u00d7 faster than CSS?<\/strong><\/summary>\n
getBoundingClientRect()<\/code>. Cheng Lou himself calls the comparison \u201cunfair,\u201d since it excludes the one-time initial measurement (~19 ms). For standard websites, the difference is irrelevant.<\/p>\n<\/details>\nDoes Pretext replace CSS?<\/strong><\/summary>\n
Do I need this for my website?<\/strong><\/summary>\n
How mature is the project?<\/strong><\/summary>\n
system-ui<\/code> fonts may cause inaccurate measurements on macOS. Production use requires careful monitoring of maturity.<\/p>\n<\/details>\nWas Pretext developed with AI?<\/strong><\/summary>\n
Editor\u2019s Reading Recommendations<\/h2>\n
\n
More from the MBF Media Network<\/h2>\n