A possible future architecture for decoupled GUIs
A distributed setup where business logic and rendering are completely separated.
1. Core idea: stop sending “drawing commands”, start sending “intent”
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.
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.
Roughly three parts:
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.
2. Possible use cases
- 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.
- 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.
- 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.
3. Why this might be interesting
- No interaction latency UI logic runs locally, so even in distributed setups it feels smooth.
- Extreme reuse Business and rendering are fully decoupled. Either side can be swapped out easily.
- Clear separation of concerns Frontend decides layout and style; backend focuses on business logic.
- Potential beyond normal apps With a strong enough protocol, this could even drive complex 3D apps or games.
4. Hard parts
- Automatic layout Very hard to do well, especially if it needs to look good. Early versions may need simple or fixed layouts.
- Component/plugin system Handling constraints, interactions, animations, etc. inside the engine is not easy to design.
- 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.