# My English is bad, this is translated by AI.

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.

Pigouvian Tax

What's so special about the find of a Roman panther?

A possible future architecture for decoupled GUIs

Proptest: Property-based testing for Rust (inspired by Hypothesis)

A reference layout for Modular Monoliths in TypeScript

A self-hosted collaborative viewer for pathology slides (Rust and WebGL2)

NIST is rethinking its role in analyzing software vulnerabilities

On the Tragedy of "The Lost Physics Soul" and the Leap to Structure

ast-grep: A CLI tool for code structural search, lint and rewriting

Creating a Multi-Agent Tool

Show HN: Gmn – A lightweight Gemini CLI in Go (68x faster startup)

Garnet: High-performance Redis alternative from Microsoft

Making changing assumptions explicit during development

I use AI DevKit to develop AI DevKit features

India offloads US bonds, piles up gold in pivot away from dollar assets

Not Moaning about AI

How Debt Bankrupted the British Empire, and Why America Is Walking the Same Path

Couple Receive $200k Settlement After 'Pungent' Indian Food Complaint

Modetc: Move your dotfiles from kernel space

Gold and Silver Signal the End of American Financial Dominance

A 2026 calendar of City of London ceremonies

Shared Claude – A website controlled by the public

The rice of Chinese Memory [video]

Post-Agentic Code Forges

AI and academic research: the Manifesto for Accelerated Exploration

Making Angular 21 SSR Work with Asp.net Core 9

Open Notebook: A Secure Alternative to Google Notebook LM

Rickshaw Run

Stop using JSON for LLM structured output

Speaker Johnson Backs Efforts to Impeach Judges over Rulings

Ask HN: Is it the right time to spend on electronics(AI Bubble get worse)?