Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ I turned Markdown into a protocol for generative UI(fabian-kuebler.com)
41 points by FabianCarbonara 6 hours ago | 17 comments

There's a lot of work happening around both generative UI and code execution for AI agents. I kept wondering: how do you bring them together into a fully featured architecture? I built a prototype:

- Markdown as protocol — one stream carrying text, executable code, and data

- Streaming execution — code fences execute statement by statement as they stream in

- A mount() primitive — the agent creates React UIs with full data flow between client, server, and LLM

Let me know what you think!

▲smahs a minute ago | parent | next [-]

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).

▲joelres 4 minutes ago | parent | prev | next [-]

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!

▲zeroq 2 hours ago | parent | prev | next [-]

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.

▲noman-land 27 minutes ago | parent | next [-]

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

▲altruios 2 hours ago | parent | prev | next [-]

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

Maybe one day someone will invent a rounder wheel.

▲doublerabbit 19 minutes ago | parent [-]

Personally I think we should move to Heptagons, they're round enough.

The wheel is what I would call, passé.

▲FabianCarbonara an hour ago | parent | prev [-]

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

▲heckintime 36 minutes ago | parent [-]

I think he's talking about CSS

▲theturtletalks 2 hours ago | parent | prev | next [-]

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 an hour ago | parent [-]

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>
    )
  });
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.

▲tantalor 38 minutes ago | parent | prev | next [-]

The nice thing about standards is that you have so many to choose from

▲iusethemouse 2 hours ago | parent | prev | next [-]

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

▲eightysixfour 2 hours ago | parent | prev | next [-]

There seems to be a lot of movement in this direction, how do you feel about Markdown UI?

https://markdown-ui.com/

▲FabianCarbonara 2 hours ago | parent | next [-]

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 hours ago | parent | prev [-]

I'd much prefer MDX.

▲wangmander an hour ago | parent | prev [-]

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.

▲Retr0id 39 minutes ago | parent [-]

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