7 Min. Lesezeit

Eine JavaScript-Bibliothek eines Midjourney-Engineers verspricht, Text-Layout im Browser radikal zu beschleunigen. 6.800 GitHub-Stars in wenigen Tagen, Hacker News im Vollbrand, auf X wird diskutiert ob CSS am Ende ist. Die Demos wirken wie Magie. Aber wer genauer hinsieht, findet eine Geschichte über Browser-Altlasten, geniale Hacks und die ewige Frage: Wann ist eine Abstraktion die Lösung – und wann wird sie zum Problem?

Das Wichtigste in Kürze

• Was: Pretext ist eine MIT-lizenzierte JavaScript-Bibliothek, die Text-Layout im Browser ohne DOM-Reflows berechnet – laut Entwickler ~500x schneller als DOM-basiertes Layout (ein Vergleich, den er selbst als „unfair“ bezeichnet)
• Wer: Cheng Lou, Midjourney-Engineer und React-Contributor, Macher von react-motion (über 21.700 Stars)
• Wie: Zwei-Phasen-Ansatz – einmalige Messung via Canvas (~19 ms für 500 Texte), danach reine Arithmetik im Hot Path (~0,09 ms)
• Für wen: Hochperformante UIs wie Chat-Interfaces, Editorial-Tools, virtualisierte Listen – nicht für Standard-Websites
• Einordnung: Technisch valider Ansatz von einem seriösen Entwickler, aber der virale Hype übertrifft den aktuellen Reifegrad deutlich

Warum das Internet ausgerastet ist

Es gibt Momente in der Frontend-Welt, in denen jemand etwas zeigt, das eigentlich nicht möglich sein sollte. Text, der in Echtzeit um beliebige Formen fließt. Chat-Bubbles, die sich pixelgenau an ihren Inhalt anpassen. Magazine-Layouts, die bei 120 fps reagieren. Im Browser. Ohne Hacks, ohne Workarounds, ohne dass die Seite dabei in die Knie geht.

Cheng Lou hat das letzte Woche vorgeführt. „Ich habe mich durch die Tiefen der Hölle gekämpft, um euch für die kommenden Jahre eines der wichtigeren Fundamente des UI-Engineerings zu bringen“, schrieb er auf X. Understatement ist nicht seine Stärke. Aber die Demos halten, was die Ansage verspricht – zumindest auf den ersten Blick.

Pretext ist die Bibliothek, um die es geht. Über 6.800 GitHub-Stars in wenigen Tagen. Auf Hacker News wurde unter dem Titel „The future of text layout is not CSS“ debattiert. Die React-Community reagierte wie auf ein neues Album ihrer Lieblingsband.

Das liegt auch am Absender. Cheng Lou ist in der Frontend-Welt kein Unbekannter. Bei Meta hat er an React, ReasonML und dem Messenger gearbeitet. Sein Side-Project react-motion (über 21.700 GitHub-Stars) ist eine der meistgenutzten Animations-Bibliotheken im React-Ökosystem. Heute baut er bei Midjourney die Frontend-Architektur mit: Bun-Stack, vanilla React, kein Framework. Fünf Vollzeit-Entwickler für Millionen User. Wenn dieser Mensch sagt, der Browser sei kaputt, hört man zu.

Das 30-Jahre-Problem, das niemand bemerkt hat

Um zu verstehen, warum Pretext existiert, muss man verstehen, was der Browser eigentlich tut, wenn er Text anzeigt. Die kurze Version: viel zu viel.

Jedes Mal, wenn berechnet werden muss, wie hoch ein Textblock ist oder wo eine Zeile umbricht, löst der Browser einen Layout-Reflow aus. Er misst Buchstaben, berechnet Abstände, bricht Zeilen um, prüft Overflow-Regeln, aktualisiert das Layout aller umliegenden Elemente. Das ist eine der teuersten Operationen im Browser. Bei einer statischen Website fällt das nicht ins Gewicht. Bei dynamischen Interfaces – Chat-Apps, Editoren, animierten Layouts, virtualisierte Listen mit tausenden Einträgen – wird es zum Flaschenhals.

Das Heimtückische: Die meisten Entwickler bemerken das Problem nie. Ihre Websites funktionieren ja. Text wird angezeigt, Zeilen brechen um, alles gut. Erst wenn man versucht, hunderte Textblöcke gleichzeitig dynamisch zu layouten – eine Chat-App, ein Whiteboard-Tool, ein Magazine-Layout-Editor – stößt man an die Wand. Und diese Wand steht da, seit Netscape Navigator 1994 das erste HTML-Layout gerendert hat.

Wie Pretext den Browser austrickst

Die Lösung von Pretext ist konzeptionell elegant und technisch aufwändig.

Phase 1 – prepare(): Text wird normalisiert, in Segmente zerlegt und über die Canvas-API des Browsers gemessen. Nicht über das DOM, sondern über die Low-Level-Font-Engine, die der Browser ohnehin mitbringt. Die Ergebnisse landen im Cache. Das dauert einmalig rund 19 Millisekunden für 500 Textblöcke. Einmal bezahlen, beliebig oft nutzen.

Phase 2 – layout(): Ab jetzt rechnet Pretext nur noch mit den gecachten Breitenwerten. Reine Arithmetik, kein DOM-Kontakt. Wo bricht die Zeile um? Wie hoch wird der Absatz? Passt der Text in diese Box? Alles beantwortet durch Mathematik, nicht durch Browser-Layout. 0,09 Millisekunden für 500 Texte.

Das ermöglicht Dinge, die mit CSS schlicht nicht gehen: Text, der dynamisch um beliebige Formen fließt. Container, die sich exakt auf die schmalste Breite für eine bestimmte Zeilenanzahl zusammenziehen (Shrink-Wrap). Magazine-artige Layouts mit variablen Spaltenbreiten – alles bei 120 Bildern pro Sekunde.

Ein Detail, das Frontend-Entwickler aufhorchen lassen dürfte: Laut Cheng Lou wurde die Engine maßgeblich mit Hilfe von Claude Code und Codex entwickelt. Die KI-Tools messen gegen die Ground Truth des Browsers, iterieren über Edge Cases und optimieren den Layout-Algorithmus. Das ist ein faszinierendes Beispiel dafür, wie KI-gestütztes Engineering aussieht, wenn die Aufgabe klar definiert und das Feedback-Signal eindeutig ist.

Die Demos: Wow-Effekt mit Fußnoten

Die offizielle Demo-Seite zeigt sieben Showcases: von Accordion-Layouts über Chat-Bubbles mit minimalem Leerraum bis zu einem Editorial-Engine-Demo mit animiertem Multi-Column-Layout, Pull Quotes und Live-Reflow. Dazu kommen Community-Demos, die Magazine-Layouts und Masonry-Grids nachbauen.

Auf den ersten Blick wirken die Demos wie etwas, das im Browser nicht möglich sein sollte. Text fließt flüssig um Hindernisse, Container passen sich in Echtzeit an, Layouts reagieren ohne sichtbare Verzögerung. Dazu die alltäglichen Probleme: Auto-Growing Textareas, mehrzeiliges Text-Centering, sogar Variable-Font ASCII Art als Proof of Concept.

Und dann klickt man die Hacker-News-Diskussion auf. Und die Fußnoten beginnen.

Was der Hype verschweigt

„~500x, but it’s an unfair comparison.“
Cheng Lou über seinen eigenen Benchmark, X, März 2026

Dass der Entwickler seinen eigenen Benchmark als „unfair“ bezeichnet, verdient Respekt. Die ~500-fache Beschleunigung im Hot Path vergleicht einen gecachten Rechenweg mit einer vollständigen Erstmessung via getBoundingClientRect(). Das ist wie die Aussage „mein Auto ist 500x schneller als deins“ – aber nur wenn man die Tankzeit nicht mitrechnet. Die Erstmessung (prepare) kostet 19 Millisekunden. Für die meisten Websites ist der Unterschied irrelevant, weil sie keine hundert Reflows pro Frame auslösen.

Demo-Qualität beim Launch: Mehrere Entwickler bemerkten, dass die Demo-Seite selbst Rendering-Probleme hatte. Text wurde abgeschnitten (overflow: hidden), auf mobilen Geräten war die Seite laut einem HN-Kommentar „fully and completely broken“. Ein Entwickler kommentierte trocken: „Die Bibliothek, die das Web reparieren will, hat eine kaputte Website.“ Inzwischen sind die meisten Probleme gefixt.

CSS konnte das eigentlich: Einige der gezeigten Layouts – Text um Formen, Exclusion Zones, Regionen – waren als CSS-Features geplant. CSS Exclusions und CSS Regions existieren als Spezifikationen. Sie wurden nie breit implementiert, weil Browser-Hersteller die Priorität anders gesetzt haben. Pretext löst also nicht ein CSS-Problem, sondern ein Browser-Commitment-Problem. Das ist ein wichtiger Unterschied.

Reifegrad: Pretext ist ein frühes Open-Source-Projekt. Der Autor dokumentiert ehrlich die Einschränkungen: system-ui als Font kann auf macOS zu ungenauen Messungen führen. Sehr schmale Container brechen innerhalb von Wörtern um. Server-Side Rendering ist noch nicht fertig. Wer heute mit Pretext in Produktion geht, ist ein Early Adopter mit allen Konsequenzen.

Für wen Pretext tatsächlich relevant ist

Die Bibliothek löst ein echtes Problem – aber ein spezifisches. Relevant wird Pretext dort, wo viele Textblöcke gleichzeitig dynamisch gelayoutet werden müssen:

• Chat-Interfaces: Messaging-Apps, die tausende Nachrichten-Bubbles virtualisieren und deren Höhe vorab berechnen müssen
• Editorial-Tools: Layout-Editoren für Magazine, Newsletter oder Präsentationen, die Text in Echtzeit um Bilder fließen lassen
• Canvas-basierte UIs: Whiteboard-Tools wie Figma oder Miro, die Text außerhalb des DOM rendern
• Virtualisierte Listen: Jede Anwendung, die hunderte oder tausende Textblöcke darstellt und deren Dimensionen kennen muss, bevor sie im Viewport erscheinen

Für DACH-Unternehmen, die eigene SaaS-Produkte mit textlastigen Interfaces bauen, lohnt es sich, den Reifegrad im Auge zu behalten. Für eine Unternehmenswebsite, ein Blog oder eine Landing Page bringt Pretext keinen messbaren Vorteil. Und das ist in Ordnung. Nicht jede Bibliothek muss die Welt retten. Manchmal reicht es, ein hartes Problem für die richtige Zielgruppe elegant zu lösen.

Einordnung: Zwischen Genie und Hype

Pretext ist kein Scam und kein leeres Versprechen. Der technische Kern – DOM-Messungen aus dem Layout-Hot-Path eliminieren und durch gecachte Arithmetik ersetzen – ist ein valider Ansatz, der für bestimmte Anwendungsfälle einen echten Unterschied macht. Dass Cheng Lou seinen eigenen Benchmark als „unfair“ bezeichnet und Einschränkungen klar dokumentiert, hebt ihn wohltuend ab von den üblichen Dev-Influencern, die jede Woche das nächste Framework zur Revolution erklären.

Die Wahrheit liegt wie so oft in der Mitte. Nicht „every website you’ve ever used“ ist kaputt. Der virale Claim ist Clickbait und wahrscheinlich bewusst gewählt. Aber das zugrundeliegende Problem ist real: Browser-Layout ist für bestimmte Anwendungsfälle zu langsam, und CSS hat Features versprochen, die nie kamen. Pretext füllt diese Lücke – elegant, performant, mit klaren Grenzen.

Was bleibt: Eine beeindruckende technische Leistung eines Entwicklers, der weiß was er tut. Eine Bibliothek, die in einem Jahr entweder fester Bestandteil des Frontend-Toolkits sein wird – oder als geniales Experiment in der „Awesome JavaScript“-Liste verstaubt. Beides wäre ein würdiges Schicksal.

Häufige Fragen

Was genau ist Pretext?

Eine MIT-lizenzierte JavaScript/TypeScript-Bibliothek, die Text-Layout im Browser ohne DOM-Operationen berechnet. Sie misst Text einmalig über die Canvas-API und berechnet danach Zeilenumbrüche, Höhen und Positionierungen rein mathematisch. Entwickelt von Cheng Lou (Midjourney, ex-Meta).

Ist Pretext wirklich 500-mal schneller als CSS?

Im Hot Path laut Entwickler ~500x: 0,09 ms für 500 Textblöcke vs. DOM-Messungen via getBoundingClientRect(). Cheng Lou selbst nennt den Vergleich „unfair“, da die einmalige Erstmessung (~19 ms) nicht eingerechnet ist. Für Standard-Websites ist der Unterschied irrelevant.

Ersetzt Pretext CSS?

Nein. Pretext ersetzt nicht den Browser-Renderer. Es nutzt die Font-Engine des Browsers als Grundlage, umgeht aber den DOM-Layout-Prozess für die Textberechnung. CSS bleibt für Styling, Farben, Abstände und alle anderen Layout-Aspekte zuständig.

Brauche ich das für meine Website?

Wahrscheinlich nicht. Pretext ist relevant für Chat-Apps, Editorial-Tools, Canvas-basierte UIs und virtualisierte Listen. Für Blogs, Unternehmensseiten oder E-Commerce bringt es keinen Vorteil. Das gibt der Entwickler selbst zu.

Wie reif ist das Projekt?

Über 6.800 GitHub-Stars, aber noch in aktiver Entwicklung. Server-Side Rendering fehlt, die Demo-Seite hatte beim Launch Rendering-Probleme. system-ui als Font kann auf macOS zu ungenauen Messungen führen. Für Produktions-Einsatz sollte man den Reifegrad beobachten.

Wurde Pretext mit KI entwickelt?

Ja. Laut Cheng Lou wurde die Engine maßgeblich mit Claude Code und Codex entwickelt. Die KI-Tools messen gegen die Ground Truth des Browsers und iterieren über Edge Cases. Das ist ein interessantes Beispiel für KI-gestützte Library-Entwicklung mit klar definierbarem Feedback-Signal.

Mehr aus dem MBF Media Netzwerk

Digital Chiefs: Digitalisierung Mittelstand 2026 – Der ehrliche Statusbericht

SecurityToday: Copilot als Sicherheitsrisiko

MyBusinessFuture: KI Made in Germany – 935 Startups

Quelle Titelbild: Pexels / Rashed Paykary (px:31343632)