A New Stateless Architecture for Server-Orchestrated UI
Unlike many server-driven UI approaches, including Blazor Server, WebForms Core introduces a fundamentally different architectural model: server-orchestrated UI built on a stateless server and server-defined UI structure. While Blazor Server maintains a stateful server-side circuit for each connected browser context, WebForms Core does not require the server to maintain a persistent component tree, render tree, or mirrored DOM state for each user. Instead, the server defines UI operations through the WebForms class and generates commands that WebFormsJS executes against the actual HTML document in the browser. This creates a clean separation between server-defined UI structure and client-side DOM execution, while preserving the stateless nature of the server architecture. The result is a lightweight and scalable model in which the server orchestrates the interface without becoming the permanent owner of its browser-side state. WebForms Core therefore approaches Server-Driven UI from a different direction: not by keeping the UI alive on the server, but by describing and orchestrating UI transformations from a stateless server.
WebForms Core 2.2 is focused on taking the server-orchestrated UI model to a higher level. The goal is not simply to add more commands, but to provide better mechanisms for rendering, state management, data transformation, formatting, arithmetic operations, and extensibility.
The direction of 2.2 is to make complex UI operations more expressive while keeping the WebForms Core architecture server-oriented, HTML-native, and independent of a separate frontend framework.
A More Expressive WebForms Model
WebForms Core uses a server-side WebForms class to generate commands that are executed by WebFormsJS in the browser:
Server
↓
WebForms
↓
Commands
↓
WebFormsJS
↓
HTML DOM
With 2.2, the focus is moving toward higher-level operations.
Instead of requiring developers to construct every transformation from small DOM commands, WebForms Core can increasingly perform formatting, text processing, arithmetic calculations, rendering operations, state detection, and other transformations directly within the WebForms execution model.
Isolated DOM Operations
One of the new capabilities in WebForms Core 2.2 is Isole.
Isole provides a high-level abstraction for working with the Transient DOM. It automatically performs the transient DOM initialization and completion around a group of operations.
This removes the need to manually manage the underlying StartTransientDOM and EndTransientDOM operations.
The result is a simpler way to isolate a complex group of DOM transformations while keeping them within the existing WebForms execution hierarchy.
Rendering and State Management
Rendering and state management are among the most important architectural directions in WebForms Core 2.2.
Complex UI updates are rarely just a single DOM operation. A rendering process may involve multiple transformations, temporary states, repeated template binding, state detection, and potentially restoring the previous state.
WebForms Core 2.2 is therefore introducing mechanisms that allow these operations to be treated as part of a larger rendering process.
Snapshot and Rollback
Snapshot and rollback provide a mechanism for preserving and restoring the HTML state of an element.
A snapshot can preserve the outerHTML of a target before a transformation. The element can then be modified, rendered, or repeatedly bound to a template. If necessary, the previous state can be restored.
Conceptually:
Current DOM State
↓
Snapshot
↓
Transform
↓
New DOM State
↓
Rollback
↓
Previous DOM State
This is particularly useful for complex rendering scenarios where several operations need to work against the same original state.
It also provides a foundation for higher-level rendering operations in which snapshot and rollback do not need to be explicitly managed by the developer.
Hash-Based State Detection
WebForms Core 2.2 also introduces GetTagHash.
The operation generates a hash from the HTML representation of a tag. The hash can be stored and later compared with a new hash to determine whether the HTML state has changed.
This provides a lightweight mechanism for detecting UI state changes without requiring the server to maintain a mirror of the browser DOM.
Conceptually:
HTML
↓
GetTagHash
↓
Hash
↓
Store
↓
Later
↓
GetTagHash
↓
Compare
This capability can become useful for state validation, conditional rendering, optimization, and future rendering mechanisms.
Rendering Without Mirroring the DOM
These mechanisms follow an important principle of WebForms Core.
The server does not need to maintain a complete representation of the browser's DOM.
Instead, the server can describe a transformation, while WebFormsJS performs that transformation against the actual HTML document in the browser.
This keeps the architecture server-orchestrated without turning the server into a permanent DOM state manager.
Formatting Data
WebForms Core 2.2 introduces formatting operations for cached and saved values.
This allows common formatting tasks to be performed directly inside the WebForms execution model.
For example:
4200
↓
4,200
A time value can also be normalized:
23:1:8
↓
23:01:08
Formatting can use regular expressions, making the mechanism useful for both simple formatting and more advanced text transformations.
For example:
(\d)(?=(\d{3})+$)
can be used to transform a numeric string into a thousands-separated representation.
This removes the need for repetitive conditional operations for common formatting scenarios.
Arithmetic Operations
WebForms Core 2.2 also brings arithmetic operations directly into the WebForms command model.
The supported operations include:
+
-
*
/
%
//
**
These operations make it possible to perform calculations directly on values used by WebForms commands.
For example, a value can be increased, decreased, multiplied, divided, processed with modulo or integer division, or used in an exponentiation operation without requiring custom JavaScript.
This is particularly useful when arithmetic is part of a larger server-orchestrated UI operation.
Text Operations
Text operations are another significant part of WebForms Core 2.2.
Instead of requiring developers to repeatedly save intermediate values and manually manipulate strings, WebForms Core can perform common string operations directly within the WebForms execution flow.
Operations include capabilities such as:
Substring
TextBefore
TextAfter
and other string transformations.
These operations make it possible to extract and transform parts of values directly in WebForms commands.
For example, a value can be processed by extracting a specific substring, obtaining the text before or after a specified value, and then passing the result to another operation.
This creates a much more expressive data-transformation model:
Fetch
↓
Text Operation
↓
Arithmetic
↓
Format
↓
Render
The significance is not the individual string methods themselves. The important part is that data transformation becomes a native part of the WebForms execution model.
Regex-Based Tag Selection
WebForms Core 2.2 also introduces the ability to select tags using regular expressions against their HTML representation.
This provides another mechanism for locating elements when conventional selectors are not sufficient.
A developer can work with the HTML representation of elements and use a regular expression to identify matching tags for further operations.
This extends the selection capabilities of WebForms Core beyond conventional CSS-oriented targeting.
Comments and Debugging
A Comment capability has also been introduced.
It allows developers to place comments within the generated WebForms command structure.
This is useful when inspecting generated Action Controls and understanding why a particular sequence of commands exists.
For complex WebForms classes, comments can make the generated command structure easier to understand and debug.
The feature is intentionally simple, but it becomes increasingly useful as WebForms classes contain more sophisticated rendering and transformation logic.
Middleware
WebForms Core 2.2 is also moving toward a middleware-based extension mechanism.
The purpose is to allow developers to add specialized JavaScript capabilities without modifying the WebFormsJS core.
For example:
form.UseMiddleware("/js/image-quality.js");
A middleware can participate in a processing stage and modify data before it continues through the normal execution flow.
For example, an image-quality middleware could process uploaded images before they are sent:
FormData
↓
Image Quality Middleware
↓
XMLHttp.send()
This makes specialized capabilities possible as independent modules.
Image processing is only one example. Similar middleware modules could provide compression, client-side transformations, specialized controls, or other browser capabilities.
The important point is that middleware extends the existing WebForms Core architecture rather than introducing a separate execution model.
From Commands to Operations
One of the broader goals of WebForms Core 2.2 is to increase the abstraction level of the WebForms language.
A WebForms class can increasingly express operations such as:
Format
Arithmetic
Text Processing
Rendering
State Detection
Snapshot
Rollback
Middleware
rather than implementing every behavior as a collection of low-level DOM commands.
This makes the WebForms class more expressive while preserving the underlying Commander-Executor architecture.
A Server-Orchestrated Rendering Architecture
WebForms Core 2.2 continues the evolution of WebForms Core as a Server-Orchestrated UI technology.
The server remains responsible for describing UI operations through the WebForms class and generated commands.
WebFormsJS remains responsible for executing those commands against the browser's actual HTML DOM.
The architecture can therefore be represented as:
Server
↓
WebForms Class
↓
Server Commands
↓
WebFormsJS
↓
HTML DOM
The new capabilities in 2.2 add higher-level layers around this architecture:
Data
↓
Transformation
↓
Formatting
↓
Rendering
↓
State Detection
↓
DOM Execution
This allows WebForms Core to handle increasingly complex interactive interfaces without requiring a separate frontend application or a client-side virtual representation of the UI.
The Direction of WebForms Core 2.2
WebForms Core 2.2 is still under development, so additional capabilities and API refinements may be introduced during development.
However, the direction is already clear.
The focus is moving from individual DOM manipulation toward a more complete model for server-orchestrated rendering, data transformation, state management, and extensibility.
The objective is to make complex interactive web applications easier to build while keeping the architecture:
- Server-oriented
- HTML-native
- Stateless at the application architecture level
- RESTful
- Compatible with HTTP, WebSocket, and SSE
- Independent of a separate frontend framework
- Extensible through WebForms and WebFormsJS
WebForms Core 2.2 is not simply another collection of commands.
It is an effort to build a more expressive foundation for Server-Orchestrated UI.
Related links
On Elanat:
On GitHub:
Top comments (0)