Perhaps "WWW SPA document"? Using markdown with highly-progressive fenced blocks?

Hypertext (one word, coined 1960s) is quite a broad category. Subcategory "WWW" could fit, as TFA seems WWW-ish. A markdown document format, and progressive rendering of tags and code, seems HTML-like. Though with greater progressiveness - code blocks with streamed execution rather than merely compilation. The progressive JSON callbacks, React, integrated client and server code execution, and server-side rendering, seem closer to WWW SPA than to HTML. Though SPA files often seem more "source" than "document". And the multiple-page "App"-ness of SPA doesn't fit well. SPA seems a better fit than "full-stack". Perhaps some name analogous to "isomorphic javascript"...?

Maybe one day someone will invent a rounder wheel.

[given what CSS has incrementally and inevitably become, it's my ever-firmer belief that DSSSL would've been the right choice in the first place]

Right now this uses React for Web but could also see it in the terminal via Ink.

And I love the "freeze" idea — maybe then you could even share the mini app.

You're right that the level of expressiveness is the key design decision. There's a real spectrum:

- pre-registered blocks (safe, predictable)

- code execution with a component library (middle ground)

- full arbitrary code (maximum flexibility).

My approach can slide along that spectrum: you could constrain the agent to only use a specific set of pre-imported components rather than writing arbitrary JSX. The mount() primitive and data flow patterns still work the same way, you just limit what the LLM is allowed to render.

Would love to hear what you learn if you explore it!

Combined with a slot mechanism, complex UIs build up progressively — a skeleton appears first, then each section fills in as the LLM generates it.

I wrote a deeper dive on how the streaming execution works technically: https://fabian-kuebler.com/posts/streaming-ts-execution/

Always Show then Ask.

Markdown UI is declarative — you embed predefined widget types in markdown. The LLM picks from a catalog. It's clean and safe, but limited to what the catalog supports.

My approach is code-based — the LLM writes executable TypeScript in markdown code fences, which runs on the server and can render any React UI. It also has server-side state, so the UI can do forms, callbacks, and streaming data — not just display widgets.

So many formats, with different tradeoffs around readable/parsable/comments/etc. I wish there was a "universal" converter. With LLM's sometimes used to edit chat traces, I'd like ingestion from md/yaml, not merely a "render from message json".

So .json `[{"role": "user", "content": "Hi"}` <-> .md ` ```json\n[{"role": "user", "content": "Hi"}` <-> above ` ```user\nHi` <-> `# User\nHi` <-> ` ```chatML\n<|user|>\nHi` <-> .html rendered .md, but with elements like <think> and <file> escaped... etc.

  const onRefresh = async () => {
    data.loading = true;
    data.messages = await loadMessages();
    data.loading = false;
  };

  mount({
    data,
    callbacks: { onRefresh },
    ui: ({ data, callbacks }) => (
      <Button onClick={callbacks.onRefresh}>Refresh</Button>
    )
  });

So the UI is generated dynamically by the LLM, but the interactions are real server-side code, not just display. Forms work the same way — "await form.result" pauses execution until the user submits.

The article has a full walkthrough of the four data flow patterns (forms, live updates, streaming data, callbacks) with demos.

My approach is the opposite bet: full code execution instead of tool calls. The agent can build any React UI from scratch with the full power of code — including client-server data flow, callbacks, streaming data.

MDX is a compile-time format for static content. This is a runtime protocol where the LLM writes code that executes as it streams, and the UIs it creates stay connected to the server.