> 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"...?
Very cool. I'm imagining using this with Claude Code, allowing it to wire this up to MCP or to CLI commands somehow and using that whole system as an interactive dashboard for administering a kubernetes cluster or something like that - and the hypothetical first feature request is to be able to "freeze" one of these UI snippets and save it as some sort of a "view" that I can access later. Use case: it happens to build a particularly convenient way to do a bunch of calls to kubectl, parse results and present them in some interactive way - and I'd like to reuse that same widget later without explaining/iterating on it again.
I quite like this! I've been incrementally building similar tooling for a project I've been working on, and I really appreciate the ideas here.
I think the key decision for someone implementing a flexible UI system like this is the required level of expressiveness. To me, the chief problem with having agents build custom html pages (as another comment suggested) is far too unconstrained. I've been working with a system of pre-registered blocks and callbacks that are very constrained. I quite like this as a middleground, though it may still be too dynamic for my use case. Will explore a bit more!
OpenUI and JSON-render are some other players in this space.
I’m building an agentic commerce chat that uses MCP-UI and want to start using these new implementations instead of MCP-UI but can’t wrap my head around how button on click and actions work? MCP-UI allows onClick events to work since you’re “hard coding” the UI from the get-go vs relying on AI generating undertemistic JSON and turning that into UI that might be different on every use.
I will say I came upon this same design pattern to make all my chats into semantic Markdown that is backward compatible with markdown. I did:
```assistant
gemini/3.1-pro - 20260319T050611Z
Response from the assistant
```
with a similar block for tool calling
This can be parsed semantically as part of the conversation
but also is rendered as regular Markdown code block when needed
Helps me keep AI chats on the filesystem, as a valid document, but also add some more semantic meaning atop of Markdown
In an agentic loop, the model can keep calling multiple tools for each specialized artifact (like how claude webapp renders HTML/SVG artifacts within a single turn). Models are already trained for this (tested this approach with qwen 3.5 27B and it was able to follow claude's lead from the previous turns).
I see potential to take over Notion's / Obsidian's business here. Imagine highly customizable notebooks people can generate on the fly with the right kind of UI they need. Compared to fixed blocks in Notion
That‘a fascinating take on the UI problem. I find myself less and less coding cause there is no real easy way to build simple UI nowerdays. Languages like go and rust gloss over the UI question and offer no real easy way. Web frameworks take the roll of a emergency UI. I most of the time still use windows.forms for fast easy statefull ui forms
There’s definitely a lot of merit to this idea, and the gifs in the article look impressive. My strong opinion is that there’s a lot more to (good) UIs than what an LLM will ever be able to bring (happy to be proven wrong in a few years…), but for utilitarian and on-the-fly UIs there’s definitely a lot of promise
Brainstorming, perhaps <>? It goes against the grain of "eval() line-by-line", even if it's handled ASAP. But it might relax the order constraint on codegen. Especially if the UI gets complex, or rendered on a "pane off to the side".
61 comments
It embodies the whole idea of having data, code and presentation at the same place.
If you're open for contributions I already have an idea for cascading styles system in mind.
> 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"...?
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]
I think the key decision for someone implementing a flexible UI system like this is the required level of expressiveness. To me, the chief problem with having agents build custom html pages (as another comment suggested) is far too unconstrained. I've been working with a system of pre-registered blocks and callbacks that are very constrained. I quite like this as a middleground, though it may still be too dynamic for my use case. Will explore a bit more!
I have been working on something with a similar goal:
https://github.com/livetemplate/tinkerdown
https://markdown-ui.com/
I’m building an agentic commerce chat that uses MCP-UI and want to start using these new implementations instead of MCP-UI but can’t wrap my head around how button on click and actions work? MCP-UI allows onClick events to work since you’re “hard coding” the UI from the get-go vs relying on AI generating undertemistic JSON and turning that into UI that might be different on every use.
```
assistant
```gemini/3.1-pro - 20260319T050611Z
Response from the assistant
with a similar block for tool calling This can be parsed semantically as part of the conversation but also is rendered as regular Markdown code block when needed
Helps me keep AI chats on the filesystem, as a valid document, but also add some more semantic meaning atop of Markdown
[1] https://github.com/FabianKuebler/fenced/blob/main/packages/l...
<> ? It goes against the grain of "eval() line-by-line", even if it's handled ASAP. But it might relax the order constraint on codegen. Especially if the UI gets complex, or rendered on a "pane off to the side".