Layoutmaster

Inspiration

I am the author of VMPrint, a popular, high-performance layout engine. When I saw the @chenglou/pretext project recently become hugely popular, I realized there was a massive demand for technology that helps bypass browser DOM reflow and prevent thrashing.

However, to do that effectively, you need real layout capabilities that can rival the browser itself—a simple measurer API like Pretext simply cannot get you very far. That's how I came up with the idea for Layoutmaster.

What it does

Through a set of simple, stateless APIs, you can take on almost every layout challenge:

• form(): given space, how does this lay out, and how tall does it get?
• fit(): given bounded space, what fits, and what remains?
• flow(): given content that overflows, where does it continue?
• pour(): given a shape instead of a rectangle, fill it.

These methods don't just give you measurements. Instead, they return already laid-out content as an array of flat boxes with exact coordinates and styles. You can then use these "pieces" to either draw onto a canvas or, better yet, lay them out as flat spans on the page so not only are they more performant (in contrary to common beliefs), they are also immediately inspectable and selectable.

By bypassing the DOM this way, you gain tremendous speed. For example, with Layoutmaster, you can display an entire 320,000-word novel (that's over a thousand pages) into a 343,912px tall masonry wall in just 400ms. The same layout via the DOM would take 10x longer to create.

And here is the interesting part: when you resize the browser window, the Layoutmaster masonry wall reflows deterministically within that same 400ms (often less) timeframe. The browser, on the other hand, would go into a frenzy, its layout failing to settle even a full 20 seconds later!

This makes it incredibly useful for meeting the demands of today's AI-generated content. But it goes way beyond accelerating web pages.

Underneath, it's still a full layout engine that's every bit as powerful as the browser itself. As such, I'm in the process of extending it into a full layout framework like Yoga. Unlike Yoga, which cannot handle text at all, Layoutmaster can create any imaginable layout—even text that wraps around organic-shaped objects as fluidly as water—and does so at speeds that were previously unheard of, often reaching over 1,000 fps even on a mobile phone.

More impressively, it handles mixed BiDi perfectly without relying on heavyweights like HarfBuzz, keeping its footprint at merely ~300KB.

How we built it

The core engine is VMPrint, which was primarily a pure JavaScript DTP engine. I simplified its print-oriented pipeline, dropped its reliance on OpenType fonts, and made it use the browser's text system instead.

This way, it uses exactly the same fonts and measurements as the browser itself, which is essential for creating layouts that achieve strict browser parity. After that, I designed the API shapes, keeping them stateless and minimalistic—a sharp contrast to today's industry obsession with complex, stateful frameworks. Of course, this would not have been possible without the raw speed of the layout engine backing it up. Finally, I created a projection layer that translates the layout results into HTML-friendly data structures that I call "pieces".

And that's basically it.

Challenges we ran into

The primary challenge was replacing the text delegate module in the original engine with one compatible with the browser. After that, with the help of CODEX, it was just a walk in the park, LOL.

Accomplishments that we're proud of

There are very few layout engines available, period—not to mention one that is as capable as the browser itself AND ten times faster (in some situations a hundred times faster) while being infinitely smaller.

This is nothing short of an engineering miracle, and easily one of the most significant pieces of foundational software of the last decade. CODEX is what helped make that miracle happen much, much sooner.

What we learned

CODEX is extremely reliable and capable. But for an unconventional architecture and codebase like this, it is important to be diligent, ensuring it stays on track and, most importantly, stays "honest."

This is understandable; as an LLM, it is trained on commonly available data. Layoutmaster's architecture and code, however, are anything but common. This meant I had to constantly fight the LLM's tendency to do things the conventional way. In fact, I'm surprised it worked at all.

If I had to provide a testimony, I would confidently say this: CODEX is the only LLM that was able to stay honest most of the time. The upgrade to 5.5, and recently 5.6 Sol, have shown giant leaps in that aspect too.

What's next for Layoutmaster

Layoutmaster is FAR more than a niche tool for dealing with DOM thrashing. It already has the backbone to become a general layout framework much more capable than something like Yoga. That is my next target: to upgrade and reposition it as a true, universal layout framework.

Built With

• typescript