Rendered at 15:36:48 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
zeroq 2 days ago [-]
If you're still looking for a name let me suggest "hyper text".
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.
mncharity 24 hours ago [-]
> 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"...?
altruios 2 days ago [-]
Every turn of the wheel someone wants to make a new one.
Maybe one day someone will invent a rounder wheel.
doublerabbit 2 days ago [-]
Personally I think we should move to heptagons, they're round enough.
The wheel is what I would call, passé.
smnrchrds 2 days ago [-]
I disagree. Hexagons are the bestagons.
Akronymus 22 hours ago [-]
What is a hexagon if not 4 triangles in a trenchcoat?
keeganpoppen 2 days ago [-]
nah heptagons are passé; nowadays it’s all about nonagons. xD
altruios 2 days ago [-]
Every day the wheel of society turns a little further off course.
Soon we'll be optimizing for minimizing the sides of a wheel (triangles are not the final form here...) /s
gwern 21 hours ago [-]
Or more precisely, isn't this reinventing notebooks (not the first JS-centric notebook either)?
inopinatus 2 days ago [-]
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]
noman-land 2 days ago [-]
If HTML happened again except this time it was markdown, maybe more non-nerds would be able to use it? XML just looks gnarly.
NL807 2 days ago [-]
Problem with the markdown approach the text will become rapidly ugly with hacks, non-standard annotations to enable same features as HTML.
fyredge 1 days ago [-]
I'm very curious. I hated how html requires angled brackets for everything and love markdown for its neatness.
What are some of the ugly hacks you've seen that were applied?
FabianCarbonara 2 days ago [-]
Ha, history does rhyme ;)
Happy if you reach out via mail!
heckintime 2 days ago [-]
I think he's talking about CSS
0ing0b0ing0 2 days ago [-]
[dead]
pbkhrv 2 days ago [-]
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.
FabianCarbonara 2 days ago [-]
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.
pbkhrv 1 days ago [-]
Did you see that Claude Code just came out with "channels" that allows for messages to be injected into the session/sent out by claude via hooks and MCP server [1]? I had CC code an integration between fenced and CC using channels and it actually worked - a little clunky since there is no streaming, but very interesting nevertheless.
Whoa, I hadn't seen channels yet — and you already got fenced working with Claude Code?! That's awesome. Would love to see what you built!
joelres 2 days ago [-]
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!
FabianCarbonara 2 days ago [-]
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!
joelres 2 days ago [-]
Will do! I'm using a JSON DSL currently, I wonder if there's a best choice for format that is both at the correct level of expressiveness and also easy enough for the LLM to generate in a valid way. I do think markdown has advantage of being very trivial for LLMs, but my current JSON blocks strategy might be better for more complex data.... will play around.
realrocker 2 days ago [-]
The streamed execution idea is novel to me. Not sure what’s it significance ?
I have been working on something with a similar goal:
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.
That is super cool. Sorry to be nitpicky but would really like to know your mental model: I didn’t understand from the blog why user waiting for a functional UI is a problem ? isn’t the partial streamed UI non-functional ?
I can see the value in early user verification and maybe interrupting the LLM to not proceed on an invalid path but I guess this is customer facing so not as valuable.
"In interactive assistants, that latency makes or breaks the experience." Why ? Because user might just jump off ?
(edited)
FabianCarbonara 7 hours ago [-]
Maybe I am a bit overdramatic ;) For me this is mostly about user experience. If the agent creates a complex mini app, the user might have to wait 30 seconds. That's 30 seconds without feedback. It's way nicer to already see information appearing - especially if that information is helpful. Also the UI can be functional already, even if it's not 100% complete!
realrocker 2 hours ago [-]
No that makes sense. Waiting for feedback might lead to churn. Pretty cool idea.
kristopolous 2 days ago [-]
Add a video or a live demo, there's still too much friction on this readme.
Always Show then Ask.
FabianCarbonara 2 days ago [-]
and I meant to say: tinkerdown looks pretty cool!
tantalor 2 days ago [-]
The nice thing about standards is that you have so many to choose from
eightysixfour 2 days ago [-]
There seems to be a lot of movement in this direction, how do you feel about Markdown UI?
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.
threatofrain 2 days ago [-]
I'd much prefer MDX.
z3ugma 2 days ago [-]
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
<Short Summary title>
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
mncharity 23 hours ago [-]
> 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.
z3ugma 21 hours ago [-]
Do you know the meme about carcinization ...how in nature, everything tends toward becoming a crab?
I think we are reinventing HTML from first principles. It's semantic structuring with a meaningful render
mncharity 16 hours ago [-]
Hmm. HTML has always had goals and tradeoffs which are in tension with many uses. XML too. Witness the very many versions of "write this instead, and it becomes HTML" - long and widely used and valued. Perhaps we collectively might have done better, but we didn't. Turns out LLMs also find different formats significantly easier to use for different things.
As a tradeoff example, yesterday I again tripped on the KISS "CDATA doesn't support HEREDOC-like prefix whitespace removal". So does one indent, compromising payloads where leading ws is significant, or not, confusing humans and llms.
Re reinvention and first principles, aside from engineering tradeoffs, it can be hard to understand design spaces and to be aware of related work. I suspect there's a missing literature to support these, but professional organizations have been AWOL, and research funding dysfunctional. And commercial conflicts of interest. And it's hard. But now coding LLMs are messing with "don't reinvent wheels" payoff tables. Perhaps we'll someday be able to be explicit about design space structure and design choice consequences too. And perhaps we're already getting transformatively more flexible around format extension and interoperation. TFA isn't just a new format - it's a github repo which will help teach LLMs how to do progressive execution of fenced code blocks, making the next format which does this potentially easier to create. "Merge in what X does, but <change request>". Yay?
IIUC, non-meme carcinization is something vaguely like "similar tradeoffs pressure towards similar forms in diverse contexts". LLMs might help us more easily understand tradeoffs, implement forms, and manage diversity?
theturtletalks 2 days ago [-]
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.
FabianCarbonara 2 days ago [-]
In my approach, callbacks are first-class. The agent defines server-side functions and passes them to the UI:
When the user clicks the button, it invokes the server-side function. The callback fetches fresh data, updates state via reactive proxies, and the UI reflects it — all without triggering a new LLM turn.
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.
mncharity 2 days ago [-]
Here's[1] the rest of the prompt which begins the video.
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).
Surac 1 days ago [-]
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
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.
Lws803 2 days ago [-]
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
rthrfrd 2 days ago [-]
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!
mncharity 2 days ago [-]
Brainstorming, perhaps `<<named-block-code-transclusion>>`? 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".
FabianCarbonara 1 days ago [-]
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!
mncharity 1 days ago [-]
Oops - that's not transclusion. Merely literate programming tangles.
iusethemouse 2 days ago [-]
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
FabianCarbonara 2 days ago [-]
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.
itmitica 1 days ago [-]
Interesting food for thought for the HITL.
2 days ago [-]
4ndrewl 2 days ago [-]
The bots that read the instruction and yet add the emoji to the _beginning_ of the PR title though. Even bigger red flag I guess?
sanjosanjo 19 hours ago [-]
This is a really cool idea, as a guy who has always been primarily a React dev
nthypes 2 days ago [-]
Why not MDX?
FabianCarbonara 2 days ago [-]
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.
dominotw 2 days ago [-]
would be nice if it wasnt just ui but other form like voice narration, sounds ect
2 days ago [-]
kevindo9x19 2 days ago [-]
[dead]
AiStockAgent62 2 days ago [-]
[dead]
ayeteas54 2 days ago [-]
[dead]
YANGBOKEE56 2 days ago [-]
[dead]
ZakDavydov30 2 days ago [-]
[dead]
wangmander 2 days ago [-]
[flagged]
Retr0id 2 days ago [-]
What's the going rate these days for decade-old HN accounts to repurpose as AI spambots?
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.
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.
The wheel is what I would call, passé.
Soon we'll be optimizing for minimizing the sides of a wheel (triangles are not the final form here...) /s
[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]
What are some of the ugly hacks you've seen that were applied?
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.
[1] https://code.claude.com/docs/en/channels-reference
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!
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!
I have been working on something with a similar goal:
https://github.com/livetemplate/tinkerdown
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/
I can see the value in early user verification and maybe interrupting the LLM to not proceed on an invalid path but I guess this is customer facing so not as valuable.
"In interactive assistants, that latency makes or breaks the experience." Why ? Because user might just jump off ?
(edited)
Always Show then Ask.
https://markdown-ui.com/
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.
````assistant
<Short Summary title>
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
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.
I think we are reinventing HTML from first principles. It's semantic structuring with a meaningful render
As a tradeoff example, yesterday I again tripped on the KISS "CDATA doesn't support HEREDOC-like prefix whitespace removal". So does one indent, compromising payloads where leading ws is significant, or not, confusing humans and llms.
Re reinvention and first principles, aside from engineering tradeoffs, it can be hard to understand design spaces and to be aware of related work. I suspect there's a missing literature to support these, but professional organizations have been AWOL, and research funding dysfunctional. And commercial conflicts of interest. And it's hard. But now coding LLMs are messing with "don't reinvent wheels" payoff tables. Perhaps we'll someday be able to be explicit about design space structure and design choice consequences too. And perhaps we're already getting transformatively more flexible around format extension and interoperation. TFA isn't just a new format - it's a github repo which will help teach LLMs how to do progressive execution of fenced code blocks, making the next format which does this potentially easier to create. "Merge in what X does, but <change request>". Yay?
IIUC, non-meme carcinization is something vaguely like "similar tradeoffs pressure towards similar forms in diverse contexts". LLMs might help us more easily understand tradeoffs, implement forms, and manage diversity?
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.
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.
[1] https://github.com/FabianKuebler/fenced/blob/main/packages/l...
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.