This is the third post in Problems Cotomy Set Out to Solve. This continues from Form Submission as Runtime . The first article argued that a screen boundary has to stay local. The second argued that form submission should be treated as a shared runtime protocol instead of page-specific glue code.
But neither idea can hold if the screen itself is unstable.
In business systems, screens are not momentary views. They stay open for hours. They hold live input, partial progress, and operational state. Yet many UI models still treat screens as render events.
Cotomy started from a different premise: a screen should have a lifecycle and a stable working surface. A screen lifecycle defines when a screen becomes operable, remains stable as a working surface, and is explicitly terminated.
The Usual Model and Its Assumptions
Common UI models assume that the screen is a renderable state:
SPA patterns assume the screen is a redrawable view, virtual DOM assumes the DOM is a regenerable representation, and component-driven UI assumes continuous re-rendering.
These approaches are not wrong. They are optimized for different lifetimes.
They work well when redraw is cheap, when the application shell owns the full interaction model, or when local state can be reconstructed without much operational cost.
But that is not the pressure I kept seeing in business systems.
The Reality of Business Screens
Business UI screens stay open for long stretches. Users pause, switch tasks, and return. Form state must survive. The DOM is not a temporary output.
An order-entry screen, a maintenance form, or an approval page is not just showing data. It is holding work in progress. The screen may contain temporary choices, field dependencies, validation messages, selected rows, modal context, and data loaded in a specific order.
That makes the DOM different from a disposable render target.
The DOM is not a rendering artifact. It is the user’s working surface. This perspective matches Cotomy’s model where a screen is treated as a lifecycle-bound unit with structural continuity (see Cotomy Reference ).
That stability matters because the previous problem, form submission as runtime, already assumes a durable screen boundary. If submit is one shared protocol, then the screen has to remain structurally coherent before submit, during submit, after validation failure, and after response reflection. Otherwise the runtime may be shared, but the actual working surface still behaves like a collection of unstable fragments.
When that surface is unstable, the user loses continuity.
What Unstable DOM Creates
When the DOM is treated as disposable, these failures appear:
focus disappears during re-render, in-progress input is lost or reset, event bindings drift or get duplicated, and UI fragments reinitialize unexpectedly.
In business screens, these failures rarely appear as dramatic crashes. They appear as hesitation, inconsistent retry behavior, modal selections that no longer match the current form state, handlers that fire twice, or values that quietly return to an older state after part of the screen updates.
This is not a UX polish issue. It is a continuity failure.
Why Boundary and Runtime Still Need Lifecycle
The first two problems in this series already point toward this conclusion.
If HTML and CSS are supposed to form one local unit, then that unit has to stay present long enough for local ownership to matter. If the screen is repeatedly rebuilt as a disposable surface, local styling and local structure may still exist, but the operational continuity of that unit becomes weaker.
Likewise, if form submission is a shared runtime protocol, then the runtime needs a stable surface on which that protocol operates. Submit, lock, reflect, and retry only remain coherent when the screen that owns those actions is not silently redefined underneath them.
In other words, local boundary and shared protocol both depend on lifecycle stability.
The Core Boundary: Screen Lifecycle
A screen has a lifecycle with three boundaries:
existence begins when the screen is mounted, stable operation continues while the working surface persists, and explicit end happens when the screen is torn down.
If these boundaries are not explicit, the system cannot guarantee stability.
This is where the idea of screen lifecycle becomes practical instead of abstract. The question is not whether something can be rendered. The question is whether the system knows when the screen becomes operable, what belongs to that screen while it is active, and what should happen when the user returns to it or leaves it.
Seen this way, the three boundaries are also three guarantees.
The existence boundary guarantees when the screen becomes valid as an operable unit. The operation boundary guarantees what remains stable while the user is working. The teardown boundary guarantees what must be released so that the screen does not leave stale handlers, broken references, or half-detached behavior behind.
Cotomy’s runtime makes those guarantees explicit at the page level. CotomyPageController defines the page lifecycle boundary, form registration binds runtime behavior to that boundary, cotomy:ready guarantees that the page has completed initialization before the screen is treated as operable, and restore behavior ties continuity to registered forms when the page returns from browser history.
Why Re-Rendering-Centric Design Doesn’t Fit
Re-rendering optimizes expression. Business UI optimizes continuity. The center of design should be DOM stability, not redraw efficiency. Long-lived UI state requires structural continuity.
This does not mean that no DOM updates should happen. Business screens still need dynamic behavior. Rows are added, dialogs open, search results refresh, and field values are reflected from API responses. The issue is not that the DOM changes. The issue is whether those changes preserve the screen as one continuous working surface or repeatedly treat it as replaceable output.
Once the second model dominates, lifecycle responsibility becomes harder to reason about. Event cleanup becomes fragile, form state continuity weakens, and the meaning of “the current screen” starts to dissolve into many local update paths.
Cotomy’s Position (Without Implementation Detail)
Cotomy treats a screen as a unit with a lifecycle. The DOM is a stable working surface. The runtime manages existence, not just rendering. The emphasis is on presence, boundaries, and continuity.
That position is closely related to the previous two articles. Cotomy does not want screen structure, style, submit flow, and continuity to be governed by four different models. It treats them as parts of one screen-level runtime boundary.
Common Misreadings
This is not an anti-SPA or anti-Virtual-DOM argument, and it is not a performance note. The point is structural continuity in business UI.
Problem Series
This article is part of the Cotomy Problem Series, which examines recurring structural failures in business UI design.
Series articles: HTML and CSS as One Unit , Form Submission as Runtime , Screen Lifecycle and DOM Stability, Form State and Long-Lived Interaction , API Protocols for Business Operations , Runtime Boundaries and Operational Safety , UI Intent and Business Authority , and Binding Entity Screens to UI and Database Safely .
