Simple pages should read like ordinary declarative C++ without exposing transport or DOM bookkeeping.
Architecture overview
A logical UI mapped onto the browser DOM.
Tatzel can expose a clean C++ object model while retaining HTML, CSS, and browser rendering as the underlying platform.
01
Page builder
The page builder is the application-facing construction interface. It creates elements beneath a known parent and gives callbacks access to the framework context they need.
02
Logical elements
A logical element represents one meaningful UI control: a button, modal, card, field, or application-specific component. It owns the interface exposed to C++ code and may correspond to more than one browser node.
class LogicalElement
{
public:
virtual ~LogicalElement() = default;
ElementId GetId() const;
std::span<ElementPart> GetParts();
};03
Element parts
Element parts describe the static DOM structure behind a logical element. A labeled input, for example, may contain a wrapper, label, input, help text, and validation message while still behaving as one C++ control.
Parts can carry the browser tag, generated identifier, parent relationship, classes, attributes, and text role needed by the renderer.
04
Renderer boundary
A renderer translates logical controls into element parts and initial markup. Keeping this behind an interface allows the framework to separate application semantics from one concrete browser representation.
class Renderer
{
public:
virtual ~Renderer() = default;
virtual Button CreateButton(...) = 0;
virtual Modal CreateModal(...) = 0;
};05
Initial render and live updates
The initial page can be emitted as a complete HTML bundle for efficient browser creation. Once connected, updates become small operations such as setting text, changing attributes, adding classes, or removing elements.
- The server constructs the logical tree.
- The renderer generates the initial DOM structure.
- The browser loads the page and opens a WebSocket.
- Later state changes emit focused DOM commands.
06
Lifetime and ownership
The framework needs explicit rules for page sessions, callback captures, and element validity. A useful public model should make invalid element access detectable while keeping normal page code lightweight.
This page intentionally presents design direction rather than a frozen API. It can evolve alongside the renderer and logical-element work.