One continuous rendering architecture

Most "server-side rendering" is a half-truth. The first paint is rendered on the server, but the moment a page needs to become dynamic, the team quietly switches to a second architecture — React, Alpine, or a pile of bespoke fetch glue — and that second layer becomes the real owner of interaction and state. At the same time templates start accumulating query logic, ad-hoc reshaping, and service calls, because nobody protected the presentation boundary structurally. The page is "SSR" in name only.

Semitexa refuses both kinds of drift. It is one coherent rendering system where the page, its regions, its deferred blocks, its live widgets, and its interactive components all stay inside a single server-owned story. The server keeps owning rendering truth from the first byte to the last patch — there is never a handoff to a client renderer that the server can no longer see.

This is the thesis the rest of this showcase demonstrates. Everything else — token-driven skins, the signed event runtime, live regions, the primitives and the grammar — is an expression of this one architecture.

The seven pillars

Semitexa's rendering model rests on seven pillars. Each one closes a door that conventional SSR leaves open.

1. Page Contract — The page response is explicit before Twig sees a single field. A typed Resource DTO shapes the response; the template renders a prepared object instead of discovering data as it goes. You can read the page's shape without reading its template.

2. Presentation Boundary — Templates are presentation surfaces, not data loaders. They consume prepared data instead of querying storage, hitting APIs, or inventing view-side mapping rules. When a template reaches into the database, Semitexa treats that as a structural failure, not a style preference.

3. Region Contract — A region is a resource with a pipeline, not a partial with lucky context. Each region (nav, sidebar, widget, footer) has its own handler flow, render context, and asset collection. You can always tell where a region's data comes from and how it refreshes, because it is declared, not improvised.

4. Late HTML — Deferred blocks stream server-rendered HTML later, instead of handing control to a client renderer. The shell paints immediately; slow regions arrive over SSE as finished HTML and get swapped into position. "Deferred" means late server HTML — never "replace SSR with client rendering once the page loads."

5. Live HTML — Reactive slots refresh from server truth without inventing a second state machine. Set a refresh cadence and the server keeps re-rendering the region; the page swaps the new HTML in place. The live widget and the shell stay one architecture instead of drifting into two.

6. Interactive HTML — Components can dispatch backend events while staying inside the SSR component model. Interactivity does not require escaping into bespoke API glue: a component declares its event contract directly, the framework signs it, and the server runs the handler. (You can see this pillar working in the live field-validation demo.)

7. Framework-Free JS — JavaScript may enhance the page, but Semitexa refuses to require React, Alpine, or Angular as a mandatory second rendering layer. When script is needed it stays as small, component-owned enhancement, because the server still owns rendering truth. Assets, scripts, and SEO live inside the same rendering system rather than becoming a parallel deployment concern.

What Semitexa refuses to become

The pillars are easier to internalise as a set of refusals. For every comfortable shortcut that turns "SSR" into a client app, Semitexa has a structural answer:

Why this is the centerpiece

These are not aesthetic preferences. They are the reason a Semitexa interface can grow from a static page into a live, interactive, collaborative one without ever changing architectures. The same Resource DTO that shapes the first paint shapes the deferred region. The same Twig that renders the page renders the live slot. The same signed-context substrate that authenticates a form authenticates a UI event. You add capability by adding declarations, not by bolting on a client framework that then owns half your app.

Every other page in this showcase is a concrete instance of one of these pillars. Read this page first; everything else will read as an application of it.