解耦图形用户界面的未来架构设想
# 我的英语不好，这段内容是由AI翻译的。
<p>一种分布式架构，其中业务逻辑和渲染完全分离。</p>
<p>1. 核心理念：停止发送“绘制命令”，开始发送“意图”。</p>
<p>目前，GUI开发（无论是本地应用还是网页应用）仍然紧密耦合。我一直认为业务层和GUI层应该完全分离，这实际上与云计算的方向非常契合。</p>
<p>我设想的是一种以意图驱动的架构。后端不再发送布局、样式、JS代码等，而是通过某种协议仅发送意图、语义和描述性数据。</p>
<p>大致分为三个部分：</p>
<p>1. 业务层
业务代码保持不变。开发者无需考虑UI细节。一个小的“语义接口”将业务操作转换为抽象的意图。</p>
<p>2. 意图协议
该协议仅描述意图、语义和数据。
示例：发送“选择日期”，而不是“打开样式为X的日历小部件”。
它可以在内存、进程间通信或网络上运行。</p>
<p>3. 渲染引擎
一个自包含的引擎，解释意图并在本地渲染UI。
所有纯UI逻辑（组件、约束、动画等）都保留在引擎内部，而不调用业务层。</p>
<p>2. 可能的应用场景</p>
<p>- 本地GUI应用
将业务逻辑、协议和引擎打包成一个程序。无需网络支持。只需像库一样链接引擎，并根据需要加载组件/插件。</p>
<p>- 现代网页应用
后端运行业务逻辑，并通过HTTP发送意图。
浏览器基本上变成了一个具有高复用性的自定义渲染引擎。</p>
<p>- 云端 + 轻客户端
类似于网页模型：业务在云端运行，渲染引擎作为轻量级客户端在本地运行。
一个引擎可以服务多个云应用，并可以热更新组件以获得新的渲染能力。</p>
<p>3. 这可能有趣的原因</p>
<p>- 无交互延迟
UI逻辑在本地运行，因此即使在分布式设置中也能保持流畅。</p>
<p>- 极致复用
业务和渲染完全解耦。任一方都可以轻松替换。</p>
<p>- 清晰的关注点分离
前端决定布局和样式；后端专注于业务逻辑。</p>
<p>- 超越普通应用的潜力
如果协议足够强大，这甚至可以驱动复杂的3D应用或游戏。</p>
<p>4. 难点</p>
<p>- 自动布局
很难做到好，尤其是当需要看起来美观时。早期版本可能需要简单或固定的布局。</p>
<p>- 组件/插件系统
在引擎内部处理约束、交互、动画等并不容易设计。</p>
<p>- 协议设计
过于详细 → 后端最终会微观管理前端。
过于模糊 → 前端缺乏必要的信息。
而在不发送代码的情况下描述UI逻辑是一个很大的挑战。</p>
查看原文
# My English is bad, this is translated by AI.<p>A distributed setup where business logic and rendering are completely separated.<p>1. Core idea: stop sending “drawing commands”, start sending “intent”<p>Right now, GUI development (native or web) is still very tightly coupled. I’ve always felt the business layer and the GUI layer should be fully separated, and this actually fits the direction of cloud computing pretty well.<p>What I’m imagining is an intent‑driven architecture. Instead of sending layout, styles, JS code, etc., the backend only sends intent, semantics, and descriptive data through some protocol.<p>Roughly three parts:<p>1. Business layer
Business code stays the same. Developers don’t need to think about UI details. A small “semantic interface” converts business actions into abstract intents.
2. Intent protocol
The protocol only describes intent, semantics, and data.
Example: send “pick a date”, not “open a calendar widget with style X”.
It can run over memory, IPC, or network.
3. Rendering engine
A self‑contained engine that interprets intents and renders UI locally.
All pure UI logic (components, constraints, animations, etc.) stays inside the engine, without calling back to the business side.<p>2. Possible use cases<p>- Native GUI apps
Bundle business + protocol + engine into one program. No networking needed. Just link the engine like a library and load components/plugins as needed.<p>- Modern web apps
Backend runs the business logic and sends intents over HTTP.
The browser basically becomes a custom rendering engine with very high reusability.<p>- Cloud + thin clients
Similar to the web model: business runs in the cloud, rendering engine runs locally as a lightweight client.
One engine can serve multiple cloud apps, and can hot‑update components to gain new rendering abilities.<p>3. Why this might be interesting<p>- No interaction latency
UI logic runs locally, so even in distributed setups it feels smooth.<p>- Extreme reuse
Business and rendering are fully decoupled. Either side can be swapped out easily.<p>- Clear separation of concerns
Frontend decides layout and style; backend focuses on business logic.<p>- Potential beyond normal apps
With a strong enough protocol, this could even drive complex 3D apps or games.<p>4. Hard parts<p>- Automatic layout
Very hard to do well, especially if it needs to look good. Early versions may need simple or fixed layouts.<p>- Component/plugin system
Handling constraints, interactions, animations, etc. inside the engine is not easy to design.<p>- Protocol design
Too detailed → backend ends up micromanaging the frontend.
Too vague → frontend lacks necessary info.
And describing UI logic without sending code is a big challenge.