> If you're still looking for a name let me suggest "hyper text".

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"...?

Every turn of the wheel someone wants to make a new one.

Maybe one day someone will invent a rounder wheel.

Or more precisely, isn't this reinventing notebooks (not the first JS-centric notebook either)?

In this timeline I suggest favouring a style semantics and specification language.

[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]

If HTML happened again except this time it was markdown, maybe more non-nerds would be able to use it? XML just looks gnarly.

Ha, history does rhyme ;) Happy if you reach out via mail!

[dead]

Exactly this!

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.

Thanks! Really interesting to hear you're working on something similar.

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!

The significance is responsiveness — instead of waiting for the LLM to finish generating the entire code block before anything happens, each statement executes as soon as it's complete. So API calls start, UIs render, and errors surface while the LLM is still streaming tokens.

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/

Add a video or a live demo, there's still too much friction on this readme.

Always Show then Ask.

and I meant to say: tinkerdown looks pretty cool!

Markdown UI and my approach share the "markdown as the medium" insight, but they're fundamentally different bets:

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.

I'd much prefer MDX.

In my approach, callbacks are first-class. The agent defines server-side functions and passes them to the UI:

  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.

> AI chats as a valid document

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.

A2UI is Google's take — declarative JSON, tool-calling based, predefined component catalog. Clean and safe but constrained.

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.

That’s what I’m building, along with the invisible unified data model underneath, that is needed to tie everything together. Always glad for feedback, reach out in my profile if it sounds interesting!

Interesting idea! The slots mechanism already handles some of this — you can mount a skeleton first and fill in named sections later as the LLM generates them. But true out-of-order transclusion could be useful for more complex layouts. Worth exploring!

Oops - that's not transclusion. Merely literate programming tangles.

Thanks! I totally agree — this isn't about replacing carefully designed UIs. It's about ephemeral interfaces you need in the moment — the throwaway dashboard for this specific dataset, the one-off form for this exact workflow. Things that would normally mean opening 3 different apps.

The goal isn't really a better markdown format — it's bringing code execution and generative UI together. The code fences run on the server: calling APIs, processing data, doing agentic work. And they can also mount reactive UIs with full data flow between client, server, and LLM.

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.

What's the going rate these days for decade-old HN accounts to repurpose as AI spambots?