8 comments

  • zeroq1 hour ago
    If you&#x27;re still looking for a name let me suggest &quot;hyper text&quot;.<p>It embodies the whole idea of having data, code and presentation at the same place.<p>If you&#x27;re open for contributions I already have an idea for cascading styles system in mind.
    • altruios1 hour ago
      Every turn of the wheel someone wants to make a new one.<p>Maybe one day someone will invent a rounder wheel.
    • FabianCarbonara42 minutes ago
      Ha, history does rhyme ;) Happy if you reach out via mail!
      • heckintime3 minutes ago
        I think he&#x27;s talking about CSS
  • tantalor4 minutes ago
    The nice thing about standards is that you have so many to choose from
  • wangmander15 minutes ago
    Using markdown as the transport layer is clever because every LLM already speaks it fluently. You&#x27;re not teaching the model a new format, you&#x27;re just giving existing behavior a runtime.
    • Retr0id5 minutes ago
      What&#x27;s the going rate these days for decade-old HN accounts to repurpose as AI spambots?
  • theturtletalks1 hour ago
    OpenUI and JSON-render are some other players in this space.<p>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.
    • FabianCarbonara55 minutes ago
      In my approach, callbacks are first-class. The agent defines server-side functions and passes them to the UI:<p><pre><code> const onRefresh = async () =&gt; { data.loading = true; data.messages = await loadMessages(); data.loading = false; }; mount({ data, callbacks: { onRefresh }, ui: ({ data, callbacks }) =&gt; ( &lt;Button onClick={callbacks.onRefresh}&gt;Refresh&lt;&#x2F;Button&gt; ) }); </code></pre> 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.<p>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 — &quot;await form.result&quot; pauses execution until the user submits.<p>The article has a full walkthrough of the four data flow patterns (forms, live updates, streaming data, callbacks) with demos.
  • iusethemouse1 hour 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
  • eightysixfour1 hour ago
    There seems to be a lot of movement in this direction, how do you feel about Markdown UI?<p><a href="https:&#x2F;&#x2F;markdown-ui.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;markdown-ui.com&#x2F;</a>
    • FabianCarbonara1 hour ago
      Markdown UI and my approach share the &quot;markdown as the medium&quot; insight, but they&#x27;re fundamentally different bets:<p>Markdown UI is declarative — you embed predefined widget types in markdown. The LLM picks from a catalog. It&#x27;s clean and safe, but limited to what the catalog supports.<p>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.
    • threatofrain1 hour ago
      I&#x27;d much prefer MDX.