Rendering model
Five short essays, part 3 of 5.
Server-side rendering and the hydration step that reconciles it against a client-rendered tree are a substantial part of what a framework compiler like Svelte's has to get right -- rendering the same component twice, once on a server and once in a browser, and making sure the two agree closely enough that the browser can take over without a visible flash or a mismatch error.
ARKlight has neither mode, by design.
arklight buildalways produces the same static HTML, once, with no server-rendered variant to keep in sync and nothing to hydrate afterward. The shipped
arklight.jsruntime attaches behavior --
Bind,
Action.*,
Show,
Repeat-- to markup that already exists, rather than re-rendering it.
Concern | A hydrating framework | ARKlight |
|---|---|---|
Initial HTML | Rendered server-side or at build time | Rendered once, at build time, always |
Client takeover | Hydration reconciles server and client trees | Runtime attaches behavior to existing markup |
Mismatch risk | A real failure mode (hydration warnings) | Not applicable -- there is only one render |
This is also why ARKlight has no large-SPA-style persistent cross-navigation app state and no general
fetch/HTTP primitive: those live naturally in a client-rendering model, not a static-output one. The
Providerescape hatch is the sanctioned way to talk to a real backend when a site needs one.