Introducing Units - A Tiny DSL for LLM-Generated UIs

A practical look at using a compact UI DSL to reduce LLM token overhead, improve structure validation, and compile cleanly to JSX.

Mar 03, 2026

Edit 1: March 21, 2026

After publishing this, I came across a Peking University/Tencent paper that independently validated the same hypothesis with production results from WeChat.

I started Units as a side project to test a simple idea:

What if LLMs could generate UI with a compact DSL instead of full JSX?

When we use LLMs to build interfaces today, they often spend tokens on verbose syntax, repeated patterns, and formatting noise. JSX is excellent for developers, but it may not be the most efficient language for a model to think in.

Units is my attempt to explore that gap.

The hypothesis

If we give models a condensed, structured UI language, they should spend fewer tokens per UI generation, keep more context available for reasoning, produce output that is easier to parse, and iterate faster in agent-style loops.

In short: less syntax overhead, more signal.

Why this matters

LLMs generating UI usually juggle layout, hierarchy, component composition, design-system constraints, data bindings, interactions, and app-specific logic.

Every token spent on boilerplate is a token not spent on decisions.

Visual: Units pipeline

The core idea is small: keep generation compact, validate early, then compile to familiar framework code.

What Units is (so far)

Units is a compact DSL that represents UI intent in a tighter format, then compiles to JSX (and potentially other targets later).

JSX

<Card className="p-4">
  <Heading level={2}>Welcome</Heading>
  <Button variant="primary" onClick={start}>Get Started</Button>
</Card>

Units DSL

card.p4[
  h2["Welcome"]
  button.primary{click:start}["Get Started"]
]

Same intent, fewer tokens, cleaner structure for machine generation.

Where JSX Still Wins

I do not think humans should hand-write most application UI in a compressed DSL. JSX is readable, debuggable, and already integrated into the tools developers use every day. Units is useful only if the author is a model and the output is an intermediate representation.

That distinction keeps the experiment honest. The question is not "can Units be prettier than JSX?" The question is "can a model produce a smaller, more validatable structure that compiles into boring JSX?"

Visual: Agentic UI generation loop

Beyond token savings

Token savings is the starting point, not the finish line. A constrained DSL may also unlock better reliability, stronger guardrails, cleaner diffs, model portability, and safer automation. The interesting part is that agents can reason at the intent level before emitting framework code.

A Practical Validation Bar

For this to be useful, a Units pipeline needs to prove more than novelty. I would expect it to beat raw JSX generation on at least three checks:

1. Structural validity: the emitted tree should parse and validate more often than JSX.
2. Repair speed: invalid output should be easier for the model to patch because the error surface is smaller.
3. Design-system fit: the DSL should restrict component names, variants, layout primitives, and tokens before the compiler emits code.

If it only saves tokens but still produces fragile UI, it is not worth adding a language layer.

Example Guardrail

Imagine an internal dashboard where cards, filters, tables, and charts must use approved components. In JSX, the model can invent props or bypass conventions with arbitrary markup. In a DSL, the validator can reject invalid variants before any code reaches the app.

That creates a useful separation. The model proposes layout intent. The validator enforces product constraints. The compiler emits framework code. The human reviews a familiar diff.

This is the part I care about most. Token efficiency is nice. Control over the generation boundary is more important.

What I am testing next

This is still an experiment, so I am keeping the tests measurable: token usage versus JSX across common UI tasks, generation quality, structural correctness, compile-time guarantees, validation ergonomics, and end-to-end latency in iterative LLM UI workflows.

Closing thought

I am not trying to replace JSX for humans.

I am exploring whether we need a better language for models, then compile to the language humans already use. If this works, we get both efficient generation and familiar runtime code.

If you are experimenting with LLM-native UI pipelines, I would love to compare notes.