You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[DISCUSS] Generative UI: letting Maka benefit directly from stronger code generation
#6173
I'd like to discuss whether Maka should add Generative UI, and how to implement it in a way that stays simple and remains useful over time.
My starting point is a hypothesis about the next six to twelve months: models will become increasingly good at writing HTML, TSX and interaction code. Generating a page or component suited to the current question will become increasingly natural.
If that happens, an answer can include an interface for the person to use directly: an adjustable simulation to explain a phenomenon, a purpose-built tool to compare choices, or an interactive prototype to explore a design.
The value of Generative UI is to turn the model's code-generation capability directly into an answer people can use. Saving a few conversational round-trips is one consequence of that capability.
For example:
When explaining wave interference, the model could generate an animation with adjustable sources, frequencies and phases, letting the person understand the changes through interaction.
When planning a trip, the model could generate an interactive page tailored to the destinations, available time and budget, with controls for changing constraints and comparing routes.
Maka's developers would not need to design every one of these interfaces in advance. The model could generate the interaction for the question, while Maka provides the host that runs and presents it.
This changes the selection question: which designs benefit directly as models improve, and which layers mainly compensate for today's limitations and could become constraints six months from now?
Comparing implementation approaches
Visual quality cannot be judged by “HTML or JSON” alone. It depends on the model, available components and libraries, design resources, and runtime. The following compares expressive freedom and maintenance trade-offs, rather than visual scores from a controlled, same-prompt evaluation.
Approach
Visual and interaction capabilities
Value and cost as models improve
Self-contained HTML/CSS/JS + sandboxed iframe
Freely composed layouts, animation, SVG, Canvas and WebGL
Uses standard Web capabilities directly and needs no TSX compilation; the host still handles isolation, resources and interaction callbacks.
TSX + a lightweight compiler and fixed dependencies
Freely generated React components, reusing Hooks, components and graphics libraries
Benefits directly from React code generation; requires compilation, module resolution and a defined dependency scope. esbuild is a compiler, not a complete sandbox.
TSX + Sandpack
Multi-file code, dependencies and hot updates, useful for interfaces that continue to evolve
Reuses an existing bundling system and reduces custom work, while introducing a heavier runtime. Sandpack Client can be used independently of its editor UI.
JSON + a registered component catalog
The model composes within the available components, layouts and actions
Design consistency, validation and cross-client rendering remain valuable; new interaction types may require developers to extend the catalog. Examples include json-render, A2UI and assistant-ui.
A compact UI DSL
An additional language for composing registered components
May reduce structured output, but adds another syntax and parser to support. OpenUI Lang is one example; its continuing benefit over standard code needs to be established.
Domain-specific chart and diagram languages
Concise descriptions and established interactions within a particular domain
Vega-Lite and Mermaid can be available tools without becoming mandatory output formats for every interface.
react-live is another reference for lightweight React previews, but it does not itself isolate code and cannot serve as the security boundary for model-generated code.
Shared components and freely generated code are also compatible. A host can offer themes, styles and common libraries for the model to reuse without requiring every interface to be expressed through a component schema.
What do existing products demonstrate?
The Way of Code presents visual works built with Claude Artifacts, including animated graphics using React, Three.js and Canvas. Examples like these show the space standard code offers for custom visuals and interactions.
Another approach is equally worth examining: ChatGPT Intelligent UI uses native, streamable components and a compiler, with models trained to make content, layout and interaction decisions. Its internal generation format is not public, so it cannot simply be assumed to use JSON.
Both freely generated code and controlled components therefore have real product examples. The question is which approach fits Maka, and which host remains simple and useful as models continue to improve.
Content format and presentation location should be separate decisions. HTML or TSX can appear within a conversation or in an Artifact pane. Saving, expanding or exporting it are additional product choices; they need not create two separate content systems.
Ecosystem size and maturity
The following is a snapshot from October 19, 2026. The npm download window is September 20–October 19, 2026.
Stars indicate interest. Downloads include repeated installs, CI and transitive dependencies; they cannot be converted directly into user counts. The difference between assistant-ui's main package and its Generative UI package also shows why an entire framework's scale cannot stand in for adoption of a new feature.
Maturity needs separate consideration:
Sandpack and react-live date from 2021 and 2017 respectively, with longer histories as code-preview infrastructure. Sandpack's latest repository push was April 24, 2025, so its maintenance status needs checking before adoption; react-live's latest push was October 5, 2026.
Approaches such as json-render and A2UI are newer and have attracted substantial interest, but project age, current feature maturity and production adoption are different things.
Tambo remains open source and self-hostable, but its README announces that its hosted Cloud will shut down on October 31, 2026.
At the product level, Anthropic reported in June 2025 that millions of users had created over half a billion Artifacts; Vercel reported in February 2026 that more than four million people had used v0 since general availability. These are vendor-reported figures, and Artifacts include multiple content types, but they show substantial adoption of model-generated, usable outputs.
These figures support further exploration. They do not replace a judgment about Maka's particular runtime and user experience.
Under KISS, what should Maka own?
Maka already has sandboxed HTML Artifact previews. I would like to start with the question: what is still missing to support standard code generated by the model?
The host needs to run or compile the code, provide necessary error feedback, reuse existing artifact identity, and return user actions to the current conversation when needed. Runtime Host continues to own Session, Turn, execution, permissions and recovery.
Supporting Generative UI need not introduce a complete application scaffold, an arbitrary npm installer, a custom UI language and another agent runtime. Tool-UI integration through MCP Apps, and the event protocol in AG-UI, should also be evaluated separately when there is a concrete need.
The criterion I would like to use is: when a model improves, can Maka obtain better interfaces directly, without continually expanding dedicated protocols and adapters? Cross-client contracts, design consistency and permission boundaries that retain long-term value should still be preserved.
Questions for discussion
Assuming models become increasingly capable of generating code, is standard HTML/TSX plus a simple host a suitable foundation for Maka?
Is HTML sufficient as a starting point? If TSX is needed, which is simpler overall: lightweight compilation with fixed dependencies, or an existing runtime such as Sandpack?
Once code generation is strong enough, which concrete problems do component catalogs, JSON protocols and dedicated DSLs still solve that justify their long-term maintenance in Maka?
What is the smallest experience needed to validate the value of model-generated code becoming an interactive answer directly?
I would like to choose the architecture on the assumption that models keep improving, and keep Maka's responsibilities as small as possible.
中文版（点击展开）
我想讨论 Maka 是否应该加入 Generative UI，以及怎样用足够简单、长期有价值的方式实现它。
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I'd like to discuss whether Maka should add Generative UI, and how to implement it in a way that stays simple and remains useful over time.
My starting point is a hypothesis about the next six to twelve months: models will become increasingly good at writing HTML, TSX and interaction code. Generating a page or component suited to the current question will become increasingly natural.
If that happens, an answer can include an interface for the person to use directly: an adjustable simulation to explain a phenomenon, a purpose-built tool to compare choices, or an interactive prototype to explore a design.
The value of Generative UI is to turn the model's code-generation capability directly into an answer people can use. Saving a few conversational round-trips is one consequence of that capability.
For example:
Maka's developers would not need to design every one of these interfaces in advance. The model could generate the interaction for the question, while Maka provides the host that runs and presents it.
This changes the selection question: which designs benefit directly as models improve, and which layers mainly compensate for today's limitations and could become constraints six months from now?
Comparing implementation approaches
Visual quality cannot be judged by “HTML or JSON” alone. It depends on the model, available components and libraries, design resources, and runtime. The following compares expressive freedom and maintenance trade-offs, rather than visual scores from a controlled, same-prompt evaluation.
react-live is another reference for lightweight React previews, but it does not itself isolate code and cannot serve as the security boundary for model-generated code.
Shared components and freely generated code are also compatible. A host can offer themes, styles and common libraries for the model to reuse without requiring every interface to be expressed through a component schema.
What do existing products demonstrate?
The Way of Code presents visual works built with Claude Artifacts, including animated graphics using React, Three.js and Canvas. Examples like these show the space standard code offers for custom visuals and interactions.
Another approach is equally worth examining: ChatGPT Intelligent UI uses native, streamable components and a compiler, with models trained to make content, layout and interaction decisions. Its internal generation format is not public, so it cannot simply be assumed to use JSON.
Both freely generated code and controlled components therefore have real product examples. The question is which approach fits Maka, and which host remains simple and useful as models continue to improve.
Content format and presentation location should be separate decisions. HTML or TSX can appear within a conversation or in an Artifact pane. Saving, expanding or exporting it are additional product choices; they need not create two separate content systems.
Ecosystem size and maturity
The following is a snapshot from October 19, 2026. The npm download window is September 20–October 19, 2026.
@json-render/core@a2ui/react@assistant-ui/react/@assistant-ui/generative-ui@openuidev/lang-core@tambo-ai/react@codesandbox/sandpack-reactreact-liveStars indicate interest. Downloads include repeated installs, CI and transitive dependencies; they cannot be converted directly into user counts. The difference between assistant-ui's main package and its Generative UI package also shows why an entire framework's scale cannot stand in for adoption of a new feature.
Maturity needs separate consideration:
At the product level, Anthropic reported in June 2025 that millions of users had created over half a billion Artifacts; Vercel reported in February 2026 that more than four million people had used v0 since general availability. These are vendor-reported figures, and Artifacts include multiple content types, but they show substantial adoption of model-generated, usable outputs.
These figures support further exploration. They do not replace a judgment about Maka's particular runtime and user experience.
Under KISS, what should Maka own?
Maka already has sandboxed HTML Artifact previews. I would like to start with the question: what is still missing to support standard code generated by the model?
The host needs to run or compile the code, provide necessary error feedback, reuse existing artifact identity, and return user actions to the current conversation when needed. Runtime Host continues to own Session, Turn, execution, permissions and recovery.
Supporting Generative UI need not introduce a complete application scaffold, an arbitrary npm installer, a custom UI language and another agent runtime. Tool-UI integration through MCP Apps, and the event protocol in AG-UI, should also be evaluated separately when there is a concrete need.
The criterion I would like to use is: when a model improves, can Maka obtain better interfaces directly, without continually expanding dedicated protocols and adapters? Cross-client contracts, design consistency and permission boundaries that retain long-term value should still be preserved.
Questions for discussion
I would like to choose the architecture on the assumption that models keep improving, and keep Maka's responsibilities as small as possible.
中文版（点击展开）
我想讨论 Maka 是否应该加入 Generative UI，以及怎样用足够简单、长期有价值的方式实现它。
我的出发点是一个面向未来半年到一年的假设：模型会越来越擅长编写 HTML、TSX 和交互代码，生成一个适合当前问题的页面或组件，会变得越来越自然。
如果这个假设成立，模型的回答就可以包含一段供人直接操作的界面：解释一个现象时生成可调整的模拟，比较几个选择时生成专用工具，讨论一个设计时生成可以体验的原型。
Generative UI 的价值，是把模型的代码生成能力直接转化为人可以使用的回答。 减少几轮提示词往返只是其中一个结果。
例如：
这些界面不必全部由 Maka 的开发者提前设计。模型可以根据问题生成交互，Maka 提供运行和展示它的宿主。
这也改变了选型问题：哪些设计能够随着模型变强而直接受益，哪些复杂度只是在弥补今天的模型能力，半年后可能反而成为限制？
比较实现路线
视觉效果不能只按“HTML 还是 JSON”判断。它取决于模型、可用组件和库、设计资源及运行环境。下面比较的是表达自由度与维护取舍，不是同一提示词下的视觉评分。
react-live 也是轻量 React 预览的参考，但它本身不提供代码隔离，不能直接充当模型代码的安全边界。
共享组件和自由代码也不矛盾。宿主可以提供主题、样式和常用库，让模型复用，而不一定要求所有界面都通过组件 schema 表达。
现有产品展示了什么效果？
The Way of Code 提供了基于 Claude Artifacts 的视觉作品，可以查看 React、Three.js、Canvas 等代码生成的动态图形。这类例子展示了标准代码承载定制视觉与交互的空间。
另一条路线同样值得参考：ChatGPT Intelligent UI 使用原生可流式组件与编译器，并训练模型进行内容、布局和交互设计。内部生成格式尚未公开，不能直接认定它采用 JSON。
因此，自由代码和受控组件都有实际产品支持。需要讨论的是：哪条路线最适合 Maka，以及在模型继续变强之后，哪种宿主仍然简单、有用。
内容格式与展示位置应该分开。 HTML 或 TSX 可以显示在对话中，也可以显示在 Artifact 面板中；是否保存、展开或导出，是另外的产品选择，不必因此建立两套内容系统。
生态规模与成熟度
以下为 2026-10-19 的快照。npm 下载区间为 2026-09-20 至 2026-10-19。
@json-render/core@a2ui/react@assistant-ui/react/@assistant-ui/generative-ui@openuidev/lang-core@tambo-ai/react@codesandbox/sandpack-reactreact-liveStars 代表关注度，下载量包含重复安装、CI 和间接依赖，不能直接换算为使用人数。assistant-ui 的主包与 Generative UI 特性包之间的差异，也说明不能用整个框架的规模代表某项新功能的采用量。
成熟度还需要分别判断：
产品层面，Anthropic 在 2025 年 6 月披露，数百万用户已创建超过五亿个 Artifacts；Vercel 在 2026 年 2 月披露，v0 自正式开放以来已有超过四百万用户。这些是厂商自报，且 Artifacts 包含多种内容，但说明模型生成可用产物已经有相当规模的采用。
这些数字支持继续探索，也不能代替 Maka 对具体运行时和用户体验的判断。
从 KISS 出发，Maka 应该承担什么？
Maka 已有沙箱 HTML Artifact 预览。我希望先讨论：在此基础上，承接模型生成的标准代码，最少还缺什么？
宿主需要解决的是运行或编译代码、提供必要的错误反馈、复用现有产物身份，以及在需要时把用户动作交回当前会话。Session、Turn、执行、权限和恢复仍由 Runtime Host 管理。
不必因为支持 Generative UI，就同时引入完整应用脚手架、任意 npm 安装器、自定义 UI 语言和另一套 Agent runtime。MCP Apps 的工具界面集成、AG-UI 的事件协议，也应在实际需要时分别评估。
我希望采用的判断标准是：模型升级后，Maka 能否直接获得更好的界面，而无需不断扩充专用协议和适配层？ 同时，仍有长期价值的跨端契约、设计一致性和权限边界也应保留。
想讨论的问题
我希望以模型持续变强为前提选择架构，并让 Maka 负责的部分尽量少。
All reactions