WebForms Core 2.2 Render: A Structural Rendering Model Without Virtual DOM

Introduction

Imagine a user profile that must be rendered repeatedly with different data. The first render shows Adriano from Olbia. The second shows Mohammad from Tehran. The third shows someone else entirely.

If every render modifies the result of the previous render, the DOM can gradually accumulate unwanted changes: a leftover attribute, a stale value, or an element that was created by an earlier operation. Over time, the structure can drift away from the original HTML.

This raises an important question:

How can a server describe a fresh UI rendering without sending the entire page again?

WebForms Core 2.2 addresses this problem with Render, a structural rendering model built around a simple idea:

Keep a stable rendering base, restore it when necessary, and apply a new set of commands to produce the desired UI.

This capability extends the Server-Orchestrated UI architecture of WebForms Core. The server acts as the commander, while WebFormsJS executes the generated commands in the browser.

Instead of maintaining a synchronized client-side application state or a virtual representation of the entire UI, WebForms Core operates directly on the existing HTML DOM.

The concepts involved are not individually new. Server-driven UI, executable commands, HTML templates, and state restoration have all appeared in different forms across web architectures. The interesting part of WebForms Core 2.2 is how these ideas are combined through a stateless server, lightweight commands, HTML-native structures, sequential DOM execution, offline command availability, and structural rendering with Render, Snapshot, and Rollback.

This article explains how that model works and where it differs from more familiar client-side rendering approaches.

The WebForms Core Rendering Model

The basic WebForms Core flow is:

Server
   ↓
WebForms
   ↓
Commands
   ↓
WebFormsJS
   ↓
HTML DOM

WebForms Core does not send a component tree to the browser. It does not require JSX, a client-side component compiler, or a virtual DOM.

Instead, the server generates commands that WebFormsJS executes against the existing HTML DOM. This architecture is referred to as Server-Orchestrated UI.

One important characteristic of this model is that it focuses on command flow rather than only data flow.

In many Server-Driven UI approaches, the server describes data or a UI representation and the client interprets that information. WebForms Core instead allows the server to orchestrate operations against the client-side DOM.

Server-Driven UI

Server
   ↓
UI Description / Data
   ↓
Client Renderer
   ↓
DOM

WebForms Core

Server
   ↓
WebForms Commands
   ↓
WebFormsJS
   ↓
DOM Operations
   ↓
HTML DOM

The server can express operations such as:

Read DOM
Modify DOM
Move data
Copy data
Replace content
Change attributes
Insert
Remove
Swap
Fetch
Bind
Render
Store
Restore

A WebForms Core response can also contain constructs such as nested conditions, foreach operations, asynchronous operations, repetition, exception handling, DOM-isolated execution, and delays.

The important distinction is that these operations are generated as commands on the server and executed by the client runtime. The server does not have to execute the browser-side DOM operations itself.

HTML and Commands Are Loosely Coupled

HTML remains the document structure, while WebForms commands provide an execution layer that operates on that structure.

HTML
  ↕
WebForms Commands
  ↕
WebFormsJS

The HTML does not have to become a component definition. Commands do not need to be embedded into every element they operate on.

This separation allows the HTML structure and command layer to evolve independently while still working together through WebFormsJS.

Commands Operate on the Result of Previous Commands

WebForms Core commands are executed sequentially.

A command does not necessarily operate only on the HTML that existed when the response arrived. A previous command can create an element, and a subsequent command can immediately operate on it.

Initial HTML
     ↓
Command 1 → Create <div id="result">
     ↓
New HTML
     ↓
Command 2 → Set content of #result
     ↓
Modified HTML
     ↓
Command 3 → Change attribute of #result
     ↓
Command 4 → Insert another element into #result
     ↓
New Result

Therefore:

The output of one command can become the input structure for the next command.

A WebForms Core response is not simply a collection of independent UI updates. It is an executable sequence of DOM operations.

The Server Orchestrates, the Client Executes

The architecture can be visualized as:

                    Server
                      │
                      ▼
               WebForms Commands
                      │
                      ▼
                  WebFormsJS
                      │
                      ▼
                 Current DOM
                      │
              ┌───────┴───────┐
              ▼               ▼
         Command 2        Command 3
              │               │
              └───────┬───────┘
                      ▼
                 New DOM State

The client is not merely a renderer of server-provided data. It provides the execution environment for server-orchestrated UI operations.

The server can therefore describe both what should happen and which DOM operations should be performed.

This command-oriented model explains how WebForms Core executes UI changes. It does not yet explain how repeated renders remain stable. That is the problem Render addresses.

What Is Render?

Consider a section of HTML containing templates:

<div id="user">
    <field>{{name}}</field>
    <a href="mailto:{{email}}">{{email}}</a>
    <field>{{phone}}</field>
    <field>{{age}}</field>
    <field>{{city}}</field>
    <field>{{country}}</field>
</div>

The server can render this section using:

WebForms form = new WebForms();

form.Render(f =>
{
    f.Replace(InputPlace.Root, "{{name}}", name);
    f.Replace("-", "{{email}}", email);
    f.Replace("-", "{{phone}}", phone);
    f.Replace("-", "{{age}}", age);
    f.Replace("-", "{{city}}", city);
    f.Replace("-", "{{country}}", country);
}, "user");

Write(form.Response());

The final argument, "user", identifies the rendering target.

The original HTML acts as the rendering base. The server then applies the requested transformations.

For example, the result could become:

<div id="user">
    <field>Adriano</field>
    <a href="mailto:[email protected]">
        [email protected]
    </a>
    <field>0145221188</field>
    <field>43</field>
    <field>Olbia</field>
    <field>Italy</field>
</div>

Only the required section changes. The complete page does not need to be regenerated.

The replacement commands describe the visible transformations, while "user" identifies the target on which the rendering process operates.

The Important Difference: Render Has a Base

The most important characteristic of Render is not simply that it replaces values. It is that the rendering operation has a stable base.

When Render is used for the first time for a target, WebForms Core establishes a copy of that target as the rendering base. The requested modifications are then applied.

On a subsequent render of the same target, the rendering process can begin from that original base again.

Initial HTML
     │
     ▼
  Snapshot
     │
     ├── Render A
     │      └── Result A
     │
     ├── Restore Snapshot
     │      │
     │      └── Render B
     │             └── Result B
     │
     └── Restore Snapshot
            │
            └── Render C
                   └── Result C

This differs from repeatedly modifying the result of the previous modification.

Suppose the first render produces:

<field>Adriano</field>

A second operation changes it to:

<field>Mohammad</field>

If every operation works directly on the previous result, the DOM becomes the accumulated result of previous operations.

With a stable rendering base, each rendering operation can instead work like this:

Base
 ↓
Render 1 → State 1

Base
 ↓
Render 2 → State 2

Base
 ↓
Render 3 → State 3

The rendering process can therefore be repeated from a known structural state.

This can be useful for:

• Forms

• Dashboards

• Configuration panels

• Dynamic records

• Filters

• Reusable UI fragments

• Server-generated interfaces

Render Is Not Just Another Replace Operation

At first glance, Render may look like a convenient wrapper around replacement commands. Its architectural role is broader.

Replace describes an individual operation:

Change this value.

Render describes a rendering process:

Start from this structural base, apply these transformations, and produce the rendering result.

This makes Render a higher-level abstraction built on top of WebForms Core's command system.

How Render Works Internally

A stable rendering base prevents accumulated mutations from becoming the starting point of subsequent renders. However, the rendering process also needs to prevent intermediate changes from leaking into the live DOM.

WebForms Core addresses this with TransientDom.

The Render method is built around two lower-level concepts:

• Snapshot / Rollback

• TransientDom

Snapshot and Rollback

A lower-level API can capture a structural state using:

Snapshot("default");

That state can later be restored with:

Rollback("default");

The basic sequence is:

Snapshot
   ↓
Modify
   ↓
Modify
   ↓
Rollback
   ↓
Modify Again

Multiple snapshots can represent different structural states:

Snapshot("empty")
Snapshot("loaded")
Snapshot("editing")
Snapshot("preview")

A target can then be restored to a selected state before applying additional commands.

                 ┌── Snapshot("empty")
                 │
HTML Target ─────┼── Snapshot("loaded")
                 │
                 └── Snapshot("editing")

Then:

Rollback("loaded")
       ↓
Apply Commands
       ↓
New UI

This makes Snapshot and Rollback useful as lower-level primitives, while Render provides a higher-level rendering abstraction.

The initial snapshot used by Render can be considered its Render Base.

TransientDom: The Isolation Layer Inside Render

The implementation of Render shows how the stable base and isolated execution work together.

// The Render Method is Sensitive to DOM Changes.
// It is Recommended to Assign a Stable ID to the Selected Element.

// This Method Utilizes the Transient DOM.
// When Selecting InputPlaces, Consider the Root of the
// Selected InputPlace Within the Method.

public WebForms Render(
    WebForms newForm,
    string InputPlace,
    string Key = "",
    bool Permanent = false)
{
    if (newForm == null)
        return this;

    string bodyData = newForm.GetWebFormsData();

    if (string.IsNullOrEmpty(bodyData))
        return this;

    if (string.IsNullOrEmpty(Key))
        Key = InputPlace;

    WebForms form = new WebForms();

    form.Exist(Permanent ? Fetch.Cache(Key) : Fetch.Save(Key));
    form.Rollback(InputPlace, Key, Permanent);

    form.Else();

    form.Snapshot(InputPlace, Key, Permanent);

    form.StartTransientDOM(InputPlace);

    AppendForm(form);
    newForm.EndTransientDOM();
    AppendForm(newForm);

    return this;
}

This reveals the sequence behind a Render operation.

1. Check for an Existing Rendering Base

form.Exist(...) checks whether a snapshot already exists for the specified key.

2. Restore or Establish the Base

If the snapshot exists, Rollback(...) restores the target to its stored structural state.

If it does not exist, Snapshot(...) captures the current state as the rendering base.

3. Open a Transient DOM Scope

form.StartTransientDOM(InputPlace) establishes an isolated rendering scope.

Subsequent modifications are applied to the cloned target rather than directly to the live DOM.

4. Apply the New Commands

The commands defined in newForm are appended and executed inside the transient scope.

5. Close the Scope and Replace the Target

The transient DOM is finalized, and the modified clone replaces the original target.

This is why the implementation includes warnings about using stable element identifiers and considering the root of the selected InputPlace when working with the transient DOM.

Because Render operates on a clone of the target rather than directly modifying the live DOM, the rendering process is isolated by design.

This provides several useful properties:

• Modifications remain within the selected rendering scope.

• Unrelated elements are not part of the rendering operation.

• The rendering base remains available for subsequent renders.

• The modified clone can replace the original target as a completed operation.

The Combined Model

Render can therefore be understood as a composition of three ideas:

Snapshot / Rollback
        ↓
Stable Rendering Base

        +

TransientDom
        ↓
Isolated Execution Scope

        +

Commands
        ↓
Structural Transformations

This makes Render a structural rendering model rather than simply a convenience wrapper around Replace.

The server orchestrates a sequence of operations:

Capture Base
     ↓
Isolate Target
     ↓
Apply Commands
     ↓
Replace Target

Render and TransientDom

TransientDom can therefore be viewed as the isolation layer that supports the Render process.

Examples

Example 1: Multiple Templates with Snapshot and Rollback

Snapshot and Rollback can be used independently of the higher-level Render method.

This is useful when a target needs to switch between different structural bases.

Consider the following HTML structure containing three language-specific templates:

<div id="user"></div>

<template id="en-user">
    <div id="user">
        <field>Name: {{name}}</field>
        <a href="mailto:{{email}}">Email: {{email}}</a>
        <field>Phone: {{phone}}</field>
        <field>Age: {{age}}</field>
        <field>City: {{city}}</field>
        <field>Country: {{country}}</field>
    </div>
</template>

<template id="es-user">
    <div id="user">
        <field>Nombre: {{name}}</field>
        <a href="mailto:{{email}}">Correo electrónico: {{email}}</a>
        <field>Teléfono: {{phone}}</field>
        <field>Edad: {{age}}</field>
        <field>Ciudad: {{city}}</field>
        <field>País: {{country}}</field>
    </div>
</template>

<template id="fa-user">
    <div id="user">
        <field>نام: {{name}}</field>
        <a href="mailto:{{email}}">ایمیل: {{email}}</a>
        <field>تلفن: {{phone}}</field>
        <field>سن: {{age}}</field>
        <field>شهر: {{city}}</field>
        <field>کشور: {{country}}</field>
    </div>
</template>

On the server side, multiple snapshots can be created and later restored based on user interaction:

WebForms form = new WebForms();

form.Snapshot("en-user");
form.Snapshot("es-user");
form.Snapshot("fa-user");

form.SetCommentEvent(
    InputPlace.AllAttributes("type", "button"),
    HtmlEvent.OnClick,
    "set-state");

form.StartIndex("set-state");

form.Rollback("user", Fetch.GetValue("$"));

form.Replace("user", "{{name}}", Fetch.GetValue("name"));
form.Replace("user", "{{email}}", Fetch.GetValue("email"));
form.Replace("user", "{{phone}}", Fetch.GetValue("phone"));
form.Replace("user", "{{age}}", Fetch.GetValue("age"));
form.Replace("user", "{{city}}", Fetch.GetValue("city"));
form.Replace("user", "{{country}}", Fetch.GetValue("country"));

Write(form.ExportToHtmlComment());

In this example:

• Three structural bases are stored using Snapshot.

• A language button can restore the corresponding snapshot using Rollback.

• Placeholder values are then replaced with the current data.

• The switching commands can be embedded into the page using ExportToHtmlComment.

This approach can be useful for interfaces where the structural template itself needs to change, such as language-specific layouts or alternative UI states.

Example 2: Render with JSON Binding

WebForms Core can render different structures using the same HTML base.

Consider:

<div id="config">
    <item>{{name}}</item>
    <a href="mailto:{{email}}">{{email}}</a>
    <item>{{token}}</item>
    <item>{{role}}</item>
    <item>{{expire}}</item>
</div>

The server can bind JSON to the template:

string json = JsonSerializer.Serialize(data);

WebForms form = new WebForms();

form.Render(f =>
{
    f.BindJSONToTemplate(
        InputPlace.Root,
        json,
        "",
        "{{value}}"
    );
}, "config");

Write(form.Response());

For example:

{
    "name": "Elanat",
    "email": "[email protected]",
    "token": "1588844848",
    "role": "admin",
    "expire": "2030-10-29"
}

The target becomes:

<div id="config">
    <item>Elanat</item>
    <a href="mailto:[email protected]">
        [email protected]
    </a>
    <item>1588844848</item>
    <item>admin</item>
    <item>2030-10-29</item>
</div>

The browser does not need to understand the application's server-side data model. The server provides rendering instructions, and WebFormsJS executes them.

Render vs. Virtual DOM

Virtual DOM approaches and WFC Render can both be used to reconstruct UI, but they use fundamentally different mechanisms.

Virtual DOM

UI State
   ↓
Virtual Tree
   ↓
Reconciliation
   ↓
Real DOM

A Virtual DOM maintains an in-memory representation of UI structure. When the UI changes, the framework compares representations and determines which changes should be applied to the real DOM.

WFC Render

Render Base
   ↓
Rollback
   ↓
WFC Commands
   ↓
Transient DOM
   ↓
Real DOM

WFC Render does not maintain a virtual representation of the DOM or perform Virtual DOM reconciliation.

Instead, it uses a previously captured Render Base as the structural starting point, restores that structure with Rollback, and executes WFC commands to produce the desired UI.

The two approaches can therefore be compared conceptually:

Virtual DOM:
Representation → Reconciliation → DOM

WFC Render:
HTML Structure → Commands → DOM

The important distinction is that Render does not introduce another representation of the DOM.

The Render Base itself is HTML structure, while WFC commands describe the transformations that should be performed on it.

WFC Render is therefore not an implementation of Virtual DOM. It is a different approach to reconstructing and transforming UI structure.

WebForms Core vs. React, Vue, and Angular

WebForms Core can also be compared with client-side rendering architectures such as React, Vue, and Angular.

A React application commonly defines UI using components and state:

function User({ user }) {
    return (
        <div>
            <div>{user.name}</div>
            <div>{user.email}</div>
        </div>
    );
}

Vue uses templates and reactive state:

<template>
    <div>
        <span>{{ user.name }}</span>
        <span>{{ user.email }}</span>
    </div>
</template>

Angular provides components, templates, dependency injection, and change detection:

<div>{{ user.name }}</div>

The architectural distinction can be represented as:

React / Vue / Angular

Application State
       ↓
Components / Templates
       ↓
Framework Runtime
       ↓
DOM

WebForms Core instead uses:

WebForms Core

Server Logic
       ↓
WebForms
       ↓
Server Commands
       ↓
WebFormsJS
       ↓
DOM

The difference is primarily where rendering orchestration takes place.

WebForms Core does not require the server's UI model to be reproduced as a client-side component tree. The server can send operations that manipulate the existing HTML structure.

For example, normal HTML can remain the structural foundation:

<div id="user">
    <field>{{name}}</field>
    <field>{{email}}</field>
</div>

There is no requirement to transform it into a framework-specific component such as <UserComponent />.

Architectural Comparison

This table describes architectural models rather than ranking the frameworks.

The comparison is about where the rendering model lives and how UI changes are represented.

Practical Implications

Render and Partial UI Updates

Traditional server-side rendering often follows this pattern:

Request
  ↓
Server
  ↓
Generate Page
  ↓
Return HTML

WebForms Core can instead work at the level of a specific HTML region:

Request
  ↓
Server
  ↓
Generate Commands
  ↓
WebFormsJS
  ↓
Update Target

For example, a page can contain:

<div id="user"></div>
<div id="config"></div>

The user region can have its own rendering lifecycle, while the config region can be manipulated independently.

This allows multiple regions of a page to be managed without requiring each region to become a client-side component.

The HTML-Native Approach

WebForms Core operates on HTML structure without requiring the document to become a component definition or a client-side application model.

This can be useful for developers who want server-side control over application logic while still supporting dynamic browser interactions.

Render and Enterprise UI

Consider a large administrative application.

A client-heavy architecture might look like:

Backend API
     ↕
Client State
     ↕
Components
     ↕
Client Router
     ↕
Client Forms
     ↕
Client Validation
     ↕
DOM

A WebForms Core application can instead use:

Backend
   ↓
WebForms Class
   |
   | WebForms Commands
   ↓
WebFormsJS
   ↓
HTML

This does not mean every application should use the same architecture.

Rather, WebForms Core provides an alternative for applications where the server already owns responsibilities such as:

• Authentication

• Authorization

• Validation

• Database operations

• Business rules

• Form processing

• Data transformation

• HTML generation

Render and Client State Management

Client-side frameworks often use application state as a central source of truth.

WebForms Core does not require the browser to become the source of truth for application business state.

A simplified flow is:

Database
   ↓
Server
   ↓
Business Logic
   ↓
WebForms
   ↓
Commands
   ↓
Browser

The browser receives the UI instructions required to reflect the server's decision.

The snapshot used by Render represents a rendering reference, not a synchronized representation of the entire application state.

Render as an Extension of WebForms Core

WebForms Core already provides a command-oriented UI architecture.

Render builds a higher-level abstraction on top of it:

DOM Operations
      ↓
Action Controls
      ↓
WebForms Commands
      ↓
Render
      ↓
Snapshot / Rollback

At different levels, the model can be understood as:

DOM level:
Change the DOM.

Command level:
Execute a sequence of UI commands.

Rendering level:
Reconstruct a target from a stable base and apply rendering operations.

Structural state level:
Store, restore, and render from named structural states.

Understanding the Architectural Combination

The individual mechanisms used by WebForms Core are not new concepts in web development. The distinctive part of this architecture is how they are combined.

The WebForms Core model brings together:

• A stateless server

• Lightweight string-based commands

• HTML templates

• Offline command storage

• Sequential DOM execution

• A stable Render Base

• Snapshot and Rollback

• Server-side UI orchestration

• Client-side command execution

The architecture can be summarized as:

Stateless Server
       +
Lightweight Commands
       +
HTML Templates
       +
Offline Command Storage
       +
DOM Execution
       +
Render Base
       +
Snapshot / Rollback

The significance comes from how these pieces work together rather than from any individual primitive.

A Shift in Responsibility

The architecture assigns clear responsibilities:

Server       → Commander
WebFormsJS   → Executor
HTML         → Structure
Commands     → Execution Layer

The server decides what should happen.

WebFormsJS executes the command in the browser.

HTML remains the fundamental structural layer.

This avoids requiring the browser to maintain a complete client-side representation of the server's rendering logic.

Command Flow Instead of Data Flow

A conventional data-driven interaction might look like:

Server → Data → Client → Client decides how to render

WebForms Core can instead operate as:

Server → Command → Client executes → DOM changes
        → Next command → DOM changes again

The result of one command can become the target or input of the next command.

This makes WebForms Core closer to a UI command execution architecture than a simple data-to-UI transport mechanism.

Small Commands, Rich UI Operations

The relationship between server-side work and client-side UI changes can be represented as:

Small Server Operation
        ↓
Small Command Payload
        ↓
WebFormsJS Execution
        ↓
Dynamic UI Result

The server does not necessarily need to calculate and send a complete representation of the page for every interaction. It can describe the operations required to transform the existing document.

HTML Can Carry UI Instructions

WebForms Core commands can be stored inside HTML comments:

<!--[web-forms]
...
-->

This allows an HTML document to carry both:

• Structural HTML

• Executable UI instructions

Commands that have already been delivered can remain available in the document and be executed by WebFormsJS when required.

This is one of the mechanisms that supports the offline capabilities described by WebForms Core.

Render Adds a Stable Structural Base

The Render capability adds another important concept to the command architecture:

Render Base
    ↓
Render A → Result A

Render Base
    ↓
Render B → Result B

The rendering process can return to a known structural starting point before applying new transformations.

With Snapshot and Rollback, the idea can be generalized:

Snapshot("base")
Snapshot("loaded")
Snapshot("editing")

Then:

Rollback("editing")
     ↓
New Commands
     ↓
New Result

This provides a structural rendering mechanism without requiring a complete client-side application state architecture.

Conclusion

WebForms Core 2.2's Render capability provides a structural rendering model in which a target can have a stable rendering base, receive transformations, and be reconstructed for subsequent rendering operations.

The basic process can be represented as:

Snapshot
   ↓
Render
   ↓
Result
   ↓
Rollback
   ↓
Render Again

This differs from traditional client-side component rendering models.

React, Vue, and Angular provide client-side rendering architectures with their own component, template, state, and runtime models. WebForms Core takes a different approach by placing UI orchestration on the server and using WebFormsJS as the client-side execution engine.

The resulting model is:

Server-Orchestrated UI
        +
Server Commands
        +
Client Execution
        +
HTML-Native Structure
        +
Structural Rendering

Render does not attempt to reproduce the Virtual DOM or the component architecture of modern client-side frameworks. Instead, it extends the WebForms Core command model with a stable rendering base and isolated execution.

The key responsibilities are straightforward:

Server       → Defines the UI operation
WebFormsJS   → Executes the operation
HTML         → Remains the structural foundation
Render       → Provides the rendering base
Snapshot     → Stores structural states
Rollback     → Restores structural states

The result is an alternative approach to building dynamic web interfaces where the server remains responsible for UI orchestration while the browser executes lightweight commands against the existing HTML DOM.

Related links

On GitHub

• WebForms Core Organizations

• WebFormsJS

• WebForms Classes