- 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.
- If HTML happened again except this time it was markdown, maybe more non-nerds would be able to use it? XML just looks gnarly.
- Every turn of the wheel someone wants to make a new one.
Maybe one day someone will invent a rounder wheel.
- Personally I think we should move to Heptagons, they're round enough.
The wheel is what I would call, passé.
- Ha, history does rhyme ;) Happy if you reach out via mail!
- I think he's talking about CSS
- 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.
- 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.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.
- The nice thing about standards is that you have so many to choose from
- 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
- [dead]
- Using markdown as the transport layer is clever because every LLM already speaks it fluently. You're not teaching the model a new format, you're just giving existing behavior a runtime.
- What's the going rate these days for decade-old HN accounts to repurpose as AI spambots?
- 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.
- I'd much prefer MDX.
37 points by FabianCarbonara 5 hours ago | 15 comments