Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Daub – A rendering spec for AI-generated UIs (two files, no build step) (daub.dev)
2 points by kulesh 5 months ago | hide | past | favorite | 1 comment
Most UI frameworks solve the wrong problem — they help developers build interfaces faster. DAUB bets on the next problem: AI generating interfaces directly.

The core idea: instead of writing component code, you describe a UI in structured JSON. DAUB renders it. No compilation, no virtual DOM diffing. The spec is the UI.

What shipped so far (v3.13): - daub.css + daub.js: 76 components, 20 theme families, two CDN links, zero build step - JSON-Render spec: AI outputs structured JSON, DAUB renders a live interface — already working in the Playground - 7-stage generation pipeline: analyze → scaffold → generate → selfCheck → verify → repair → visual diff - 189 pre-made blocks across 34 categories with multimodal RAG retrieval - MCP server on Cloudflare edge: generate_ui, render_spec, validate_spec, get_component_catalog — any MCP client (Claude, Cursor, custom agents) can generate DAUB interfaces without writing a line of component code

What's coming: - v3.14: Action bindings — buttons that POST to real endpoints, forms with submit handlers, shareable URLs, version history. Generated UI becomes functional and outlives the session. - v4.0 (Intent Engine, in progress): "I need to track my expenses" → spending dashboard with charts, filters, input form. Context-aware: location, time, history inform the output. - v5.0 (Agent Runtime): multi-agent orchestration where one agent fetches data, another picks layout, a third wires actions. The interface is a byproduct of understanding, not a thing you build.

The underlying bet: as AI generates more of the interface layer, value accrues to whoever owns the rendering spec that agents target. DAUB wants that spec to be small, inspectable, text-diffable, and easy for both humans and models to work with — not locked inside a framework.

It's not competing with React or shadcn/ui. It's the layer underneath whatever generates the UI.

Playground: https://daub.dev/playground.html Roadmap: https://daub.dev/roadmap MCP server + GitHub: https://github.com/sliday/daub

Happy to get into the spec format, the complexity-routing pipeline, or how the MCP integration actually works.



Did designing for LLM output first actually change the component API, or does it mostly live in the docs and tooling?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: