Cheng Lou is the engineer behind Pretext, the pure-JavaScript text layout library that's been one of the most-discussed open-source releases of 2026. To understand why Pretext exists in the form it does — and why it was credible the moment it landed — it helps to understand who Cheng Lou is, what he built before it, and the through-line that connects all of his work.
This page is for the developers who searched for "chenglou pretext" or "cheng lou pretext" — usually after seeing the library mentioned and wanting to know who's behind it before adopting it. The TL;DR: Cheng Lou has been quietly building deeply influential UI infrastructure for a decade, and Pretext is consistent with everything he's done before.
react-motion, ReScript (formerly Reason) contributor, Midjourney engineeringIf those credentials look like they cross several different domains — UI animation, language tooling, generative AI, low-level layout — that's because they do, and the connecting thread is what Pretext makes legible.
Cheng Lou joined the React core team at Facebook in the mid-2010s, when React was still in the process of becoming the dominant frontend library. He was active in the React Conf circuit, gave talks on the architecture of the library, and contributed to the parts of React's design that have aged best — the parts that treat UI as a system of pure functions over data, and that minimize implicit state.
The talk most worth watching is "On the Spectrum of Abstraction" from React Conf, which takes a position that becomes important to understanding Pretext: that good abstractions are the ones that don't force you to give up either expressiveness or control. Pretext is, in this lens, a layout abstraction that preserves both — you get a function call that gives you the answer, and you get the underlying data that produced it.
He wrote react-motion, the spring-physics animation library that replaced explicit easing curves with declarative spring configurations. Anyone who has fought with CSS keyframe animations has felt the difference: instead of describing the trajectory, you describe the destination and let physics interpolate. Pretext applies the same impulse to text — instead of asking the browser to lay out the text and then reading back the answer, you describe the inputs and let math compute the answer directly.
After his React core years, Cheng Lou contributed substantially to ReScript (then called Reason), the OCaml-derived language that compiles to JavaScript. ReScript's design priorities — small bundle output, fast type checking, predictable performance — show up in Pretext too. The library is roughly 15KB minified, has zero dependencies, and is type-strict in TypeScript without using runtime reflection.
The cultural fingerprint is also visible. ReScript and OCaml communities treat performance as a first-class design concern, not an optimization to layer on at the end. They favor data-oriented APIs over object-oriented ones — small functions over data, rather than methods bolted to classes. Pretext's API is data-oriented in exactly this style: prepare(text, font) returns plain data; layout(prepared, width) takes plain data and returns plain data. There are no instance methods, no inheritance, no event emitters. This isn't accidental.
Cheng Lou later joined Midjourney as a senior engineer, working on the image generation product's interface. Midjourney's product surface is, paradoxically, deeply text-driven for a generative-image platform — prompt inputs, prompt history, chat-like job queues, large amounts of metadata per generation. Building a fast, responsive UI for that workload meant confronting the cost of DOM-based text measurement at scale.
This is the ground zero for Pretext. The library was extracted from real production constraints at Midjourney, where the text layout cost showed up clearly enough in the frame profiler that "what if we just didn't use the DOM" became a serious question. The answer turned into a usable, general-purpose library, and the library turned into a public release.
The fact that Pretext is "AI-friendly" — meaning that LLMs and code generators can use it to validate UI layouts without rendering them — is not coincidental. It's the natural extension of using deterministic layout in a workflow where machine-generated UI is becoming routine.
Three design decisions in Pretext become legible when you know the author's background:
1. The two-phase split. prepare() is expensive; layout() is cheap. This is the same split between "ahead-of-time work" and "per-frame work" that React itself uses for component reconciliation, and that react-motion uses for spring integration. The principle: pay the cost where the work doesn't need to be repeated.
2. The "no DOM" stance. Skipping the DOM isn't a stunt — it's a refusal to be coupled to the browser's rendering schedule. It's the same impulse that drove React's virtual DOM in the first place: building a parallel, controllable representation of the thing you care about, and only synchronizing with the browser at boundaries you control.
3. The narrow API. Eight exported functions for a complete text layout engine. This is a ReScript-flavored aesthetic — small, composable, no hidden state, no mutable instance methods. It's the opposite of the "framework with a thousand methods" style of API design.
Pretext landed publicly in March 2026 with a Twitter announcement that hit 16 million views in a week. The repo crossed 7,000 stars in three days and is now past 29,500. Linus Ekenstam wrote that Pretext "will have implications and ripples in screen UIs for the foreseeable future. Maybe decades." Simon Willison wrote a substantial summary on his blog. Several Medium long-reads followed within a week.
The reception is interesting because Pretext is, at first glance, an unsexy library — text measurement doesn't sound like a topic that should generate millions of views. The reason it did is that the implications cascade. If text measurement is finally fast, then virtual scrollers can have correct variable heights without jitter; chat clients can reflow on resize without dropping frames; editors can wrap text at user-controlled widths in real time; games can use individual characters as scene primitives; AI-generated UIs can be layout-validated programmatically. None of these were impossible before; all of them were expensive enough that you'd think twice.
Cheng Lou's reputation made the library credible the moment it shipped — engineers familiar with react-motion knew the author would care about both correctness and performance, which is the exact pair you need to trust for a layout engine.
The author's own framing of Pretext, drawn from his Twitter and the README, is consistent: this is a foundation, not a product. The library does one thing — measure and lay out text — and is opinionated about not doing more. Renderers, framework adapters, and higher-level helpers are explicitly out of scope and explicitly invited to be built in the community. The official demos at chenglou.me/pretext are showcases, not tutorials.
A recurring theme in his commentary: text is a design material, not a content container. Designers have always known this. Developers, constrained by the cost of measurement, have largely treated text as a static blob with limited interactivity. Pretext is meant to remove the cost constraint and let developers treat text the way designers always have.
Cheng Lou is reachable through GitHub issues and discussions on the Pretext repo. He maintains a personal site at chenglou.me and posts about the library and other work on Twitter under the same handle. The library's roadmap, to the extent there is a public one, is visible through the repo's milestones and release notes — the most likely future expansions are additional white-space modes and more script-specific segmentation behavior, both driven by community use cases that surface in issues.
If you're evaluating Pretext for a production codebase and want to know whether the maintainer responsiveness will hold up: the issue tracker speed, the PR review tempo, and the explicit narrowness of scope are all healthy signals. The maintainer is responsive but conservative — exactly the temperament you want for a library you intend to depend on.
If you came here to find Cheng Lou's work, the canonical links are github.com/chenglou and chenglou.me. If you want to skim what Pretext actually does, the Pretext library overview on this site is 1,500 words on the API. If you want to understand the architecture, the How Pretext Works deep dive explains the two-phase pipeline. If you want to see the library in motion, the 18-demo community showcase is where to go.
The library is the best argument for the author. The cleanest way to evaluate Cheng Lou's design taste is to read the API, then watch the demos, then read the issue tracker. It holds up.
pretext.cool is a community-maintained showcase, not affiliated with Cheng Lou or the official Pretext project. Source library: github.com/chenglou/pretext.