DEV Community: Elanat Framework

Return template

Elanat Framework — Thu, 05 Nov 2026 21:25:53 +0000

Introduction

A well-structured web application should keep presentation and application logic separate. The View should primarily describe the HTML structure, while server-side code handles data processing and application behavior.

CodeBehind is a .NET Core framework built around this separation. Unlike approaches that embed server-side logic directly into HTML, CodeBehind provides mechanisms for keeping the View focused on presentation.

However, loops and conditional statements can make this separation difficult to maintain.

The Challenge of Dynamic Content

Consider a navigation menu generated from a collection of pages. In Razor, the implementation might look like this:

<div class="navigation">
    @foreach (var page in Model.Pages)
    {
        <a href="@page.Path">@page.Title</a>
    }
</div>

Although this syntax is convenient, the View now contains both HTML and server-side control flow.

Another approach is to generate the HTML entirely in the Controller:

model.MenuHtml = "<div class='navigation'>";

foreach (var page in pages)
    model.MenuHtml += $"<a href='{page.Path}'>{page.Title}</a>";

model.MenuHtml += "</div>";

This moves the logic out of the View, but makes HTML structures harder to read and maintain in server-side code.

CodeBehind addresses this problem through Return Templates.

Understanding Return Templates

Return Templates allow developers to define HTML structures separately from the loops and conditions that generate them.

The main idea is simple: a Return Template is initially assigned to a template variable. When the template is processed, its returned content replaces that variable. This process can happen recursively, allowing multiple template levels to be resolved.

CodeBehind supports two template syntaxes:

Razor Syntax
Standard Syntax

Each syntax has its own template notation.

A Practical Example

Let's create a navigation menu using Razor Syntax.

First, define the HTML structure in the View:

<div class="navigation">
    @#Menu={<a href="@#PageUrl">@#PageTitle</a>}
</div>

Next, define the Return Template:

@#Menu{
    @foreach (PageItem page in model.PageItemList)
    {
        @#Menu
    }
}

Finally, define the values used by each menu item:

@#PageTitle{@page.Title}
@#PageUrl{@(((page.Path == "main") ? "/" : page.Path))}

The processing takes place in multiple stages:

Stage 1: The Return Template generates the repeated menu structure and replaces the initial Menu template variable.

Stage 2: The returned content is inserted into the HTML structure.

Stage 3: The remaining template variables, such as PageTitle and PageUrl, are replaced with their corresponding values.

The final output contains the generated navigation links without requiring the loop to be written directly inside the HTML structure.

Standard Syntax Support

Return Templates are also available in Standard Syntax.

The equivalent HTML structure can be written as:

<div class="navigation">
    <#Menu=<a href="<#PageUrl#>"><#PageTitle#></a>#>
</div>

The corresponding Return Template uses the Standard Syntax notation:

<#Menu
<% foreach (PageItem page in model.PageItemList)
{
    <#Menu#>
}
%>
#>

CodeBehind also handles transitions between standard server-side code blocks and returned template content, so developers do not need to manually manage every syntax boundary.

Why This Approach Matters

Return Templates provide a way to handle dynamic HTML without sacrificing the separation between presentation and server-side logic.

This approach is particularly useful for:

Dynamic navigation menus
Repeated HTML structures
Nested templates
Complex page layouts
Applications where multiple developers work on presentation and backend logic

Instead of moving HTML generation into Controllers or placing extensive control-flow statements inside Views, developers can keep each part in its appropriate place.

Conclusion

Keeping presentation separate from application logic is not always straightforward, especially when pages contain dynamic and repetitive content.

CodeBehind Return Templates provide another way to solve this problem. By separating the HTML structure from the server-side logic responsible for generating repeated content, developers can maintain cleaner Views and more manageable server-side code.

The result is a more consistent Code-Behind architecture, particularly in applications with complex presentation requirements.

Working with templates in View

Elanat Framework — Thu, 05 Nov 2026 21:25:06 +0000

Introduction

As web applications grow, maintaining repeated HTML structures across multiple pages can become a challenge. Page headers, product cards, information panels, and other common elements often share the same markup.

Copying these structures into every view increases duplication and makes future changes more difficult.

CodeBehind addresses this through its Template system. It allows developers to define reusable sections of a page and insert them into other parts of the view.

Templates can be defined directly inside a page or stored in external files. Both Razor Syntax and Standard Syntax are supported.

Creating Your First Template

Consider an online store where several pages display product information using the same HTML structure.

Instead of repeating the markup for every product, we can define a template named ProductCard.

Here is an example using Razor Syntax:

@#ProductCard{
<div class="product-card">
    <img src="@model.ProductImage" alt="@model.ProductName" />
    <div class="product-info">
        <h3>@model.ProductName</h3>
        <p>@model.ProductDescription</p>
        <span class="price">@model.ProductPrice</span>
    </div>
</div>
}

The template can then be referenced wherever its content is needed:

<section class="products">
    @#ProductCard
</section>

When CodeBehind processes the page, the template reference is replaced with the content defined in ProductCard.

This allows developers to maintain a single definition of a reusable HTML structure rather than duplicating it throughout the application.

The Same Example in Standard Syntax

CodeBehind provides the same capability through Standard Syntax.

The ProductCard template can be defined as follows:

<#ProductCard
<div class="product-card">
    <img src="<%=model.ProductImage%>" alt="<%=model.ProductName%>" />
    <div class="product-info">
        <h3><%=model.ProductName%></h3>
        <p><%=model.ProductDescription%></p>
        <span class="price"><%=model.ProductPrice%></span>
    </div>
</div>
#>

To insert the template, use:

<section class="products">
    <#ProductCard#>
</section>

Both examples demonstrate the same concept using their respective syntax conventions.

Organizing Templates in External Files

For larger applications, keeping all template definitions inside individual pages may not be the best approach.

CodeBehind supports external template files through the .astx extension. This makes it possible to organize reusable structures separately from the main page.

For example, create the following file:

/templates/product_card.astx

The file contains the template definition:

@#ProductCard{
<div class="product-card">
    <img src="@model.ProductImage" alt="@model.ProductName" />
    <h3>@model.ProductName</h3>
    <p>@model.ProductDescription</p>
    <span>@model.ProductPrice</span>
</div>
}

You can reference this external template from a page using Razor Syntax:

@page
@template "/templates/product_card.astx"

The equivalent Standard Syntax declaration is:

<%@ Page Template="/templates/product_card.astx" %>

The .astx extension is optional when specifying the template path. Therefore, the following path is also valid:

/templates/product_card

This approach allows multiple pages to use the same external template without maintaining separate copies of its HTML structure.

Keeping Views Consistent Across an Application

External templates are particularly useful when several sections of an application follow the same design conventions.

For example, an online store might use shared templates for:

Product cards
Category panels
Customer information sections
Order summaries
Notification messages

If the design of a product card changes, developers only need to update its template instead of searching through multiple views.

This also makes collaboration easier because developers can work on individual page structures while shared HTML components remain centrally organized.

Conclusion

The Template system in CodeBehind provides a practical way to organize and reuse HTML structures.

By supporting inline definitions, external .astx files, Razor Syntax, and Standard Syntax, it gives developers different options for managing their view structures.

Rather than duplicating the same markup across an application, developers can define a template once and reuse it wherever necessary.

Template feature is an important part of CodeBehind's approach to maintaining clean, organized, and reusable views.

WebForms Core 2.3 Progress Update: Component Begin, WebForms Core Begin!

Elanat Framework — Thu, 29 Oct 2026 16:31:18 +0000

WebForms Core 2.3 is getting close.

Around three to four weeks remain before the release, and a large part of the planned work has now been implemented. At this stage, development is mainly focused on completing the remaining pieces, integration, testing, and refining the new architecture.

This is a progress update rather than another roadmap announcement. The features already explained in the previous 2.3 announcement are intentionally not repeated here. Instead, this post focuses on the new implementation work that has been completed or is now reaching completion.

Component System

One of the most important developments in WebForms Core 2.3 is the implementation of the component execution boundary.

The new BeginComponent method establishes a DOM scope for a component.

For example:

BeginComponent("{component1}");

The important part is that BeginComponent does not need to know where the component exists in the DOM.

When the event is executed on the client, WebForms Core starts from the element that triggered the event and walks upward through its parent elements until it reaches the component boundary specified by BeginComponent.

At that point, a TransientDom is created for that component area.

From then on, the Action Controls associated with that execution operate within the component's own DOM area.

This creates an important separation between component instances.

For example, if a page contains several instances of the same component, an event triggered inside one instance does not need to search or operate across the DOM of the other instances.

The mechanism also covers:

Buttons and their events
Async execution
Async conditions
Intervals
PreRunners
Action Controls executed after the component boundary is established

There is also special handling for CommentBack. When CommentBack is involved, the component's TransientDom is used so that the CommentBack operation is performed only once for that component scope.

DoComponent

DoComponent takes this one step further.

Instead of requiring the developer to manually establish every component boundary, DoComponent automatically generates the required BeginComponent instructions.

It also creates a component boundary for each generated index where necessary.

This means the component mechanism can be used both explicitly:

BeginComponent("{component1}");

and through higher-level component generation with:

DoComponent(...);

The result is a scoped execution model without requiring server-side UI rendering.

The component system is therefore no longer just a planned concept in WebForms Core 2.3. Its execution mechanism is now being implemented directly inside the WebForms Core command model.

Component Begin, WebForms Core Begin.

RenderList

A new declarative method called RenderList has also been added.

Previously, rendering a collection could require combining several operations such as foreach, AddText, template binding, and other related instructions.

RenderList provides a higher-level abstraction that combines these operations.

For example:

form.RenderList(
    inputPlace: InputPlace.Class("series-container"),
    template: Fetch.LoadHtml("/api/template.html", "SeriesSite"),
    pattern: "{{value}}",
    path: "[0]",
    in_: JsonSerializer.Serialize(row)
);

The method is designed to simplify repeated template rendering while keeping the implementation declarative.

TransientDom is also handled automatically.

The goal is not to introduce another rendering engine, but to provide a simpler way to express a common WebForms Core operation.

GetFormJSON

A new GetFormJSON method has been added to the Fetch class.

It provides a direct way to retrieve the values of a form and represent them as JSON.

This gives WebForms Core a simple mechanism for moving form data into JavaScript-side processing without requiring developers to manually construct the JSON structure.

It also establishes a foundation for more advanced data handling features being developed for the new Variable system.

A New Variable System

Another major area of development is the new Variable mechanism.

Instead of creating a simple mirrored-value structure, WebForms Core 2.3 is moving toward a more advanced variable system.

The idea is to allow values such as:

{{value}}

to become actual variables within a defined scope.

The variable information can be represented as a name/value list in an INI-like structure stored through HTML comments within the relevant tag scope.

When a value changes, the corresponding bound values can be updated as well.

If the variable structure does not already exist, the system can create it automatically.

The Variable system is being separated from form data management.

The two concepts are therefore treated independently:

[variable]
[form-data]

This distinction is important because a variable is not necessarily form data, and form data does not necessarily represent the state of a component or element.

The retrieval side of this mechanism is being organized around FetchVariable, while operations such as SetVariable and BindVariable provide ways to update and bind values.

SetVariable is being designed to accept arbitrary data, convert it into JSON when appropriate, and then update the Variable structure.

The Variable system is also being extended with operations for manipulating values, including replacement, arithmetic operations, text extraction, appending, and prepending.

This is one of the larger pieces of the 2.3 data-management work and is still being refined.

Page-Level Race Condition Protection

Another important part of the current development is protection against stale operations.

Consider a user who quickly performs two actions:

Change the language to English.
Immediately change the language back to Persian.

If the first request takes longer to return, its response could arrive after the second request.

Without protection, an older response could modify a page that has already moved to a newer state.

WebForms Core 2.3 is being developed to treat these operations as ordered requests.

The request execution model will track requests with increasing identifiers. In addition to the existing Action Control execution queue, request execution itself is being tracked.

When the page changes, the system can determine whether a pending request or Action Control belongs to an older page state.

If it does, it becomes obsolete.

The old operation must then be ignored even if its response has already arrived.

This provides protection against several related problems:

Race Conditions — multiple operations competing to update the page
Stale Responses — a response belonging to an older page state
Cancellation — preventing obsolete Action Controls from executing
Out-of-order responses — ensuring that an older response cannot overwrite a newer state

The important point is that this is not limited to server responses.

The same protection must apply to Action Controls that are already waiting in the client execution flow.

The goal is a simple rule:

Once the page has moved to a newer state, operations belonging to the previous state must no longer be allowed to modify the current page.

This is especially important for fast user interactions and applications where multiple server requests can be generated within a very short period.

Replacing the `*` Magic Character in DeleteAll

A protocol-level ambiguity in DeleteAll has also been addressed.

Previously, * was used as a special value to represent "delete everything".

For example:

Add("do" + InputPlace, "*");

and:

Add("dk" + InputPlace, "*");

The problem is that * can also be a legitimate value.

If an actual <option> or checkbox value is exactly *, the protocol cannot distinguish between:

Delete the item whose value is *

and:

Delete all items

WebForms Core 2.3 replaces this magic-character approach with a dedicated flag structure.

This removes the ambiguity and allows * to be treated as a normal value when necessary.

SafeValue Now Handles HTML Encoding

SafeValue has also been improved.

It now performs HTML encoding in addition to its existing processing, providing a centralized mechanism for safely handling values that are inserted into HTML-related output.

The goal is to avoid requiring developers to remember separate encoding operations in different parts of the framework.

UpdateLineByIndex Fix

An edge case involving empty values in UpdateLineByIndex has been fixed.

Previously, an empty value could result in an additional = being generated for an Action Control that did not actually contain an assigned value.

This could produce malformed or ambiguous command output.

The new behavior correctly preserves empty values without introducing an unnecessary assignment character.

WebFormsJS Improvements

Several internal improvements have also been made to WebFormsJS.

The options section has been converted to an Object Initializer structure.

This reduces the amount of code and makes the configuration structure easier to read and maintain.

WebFormsOptions has also been renamed to WFO, reducing the size of the library and simplifying the API.

Two non-ASCII characters have been removed from the WebFormsJS source as part of the ongoing effort to keep the client-side library compact and predictable.

`<main>` Becomes the Default Location

One of the more practical changes in WebFormsJS 2.3 is the default location used by:

ResponseLocation
StateBodyLocation

The default has been changed from:

<body>

to:

<main>

There is also an automatic fallback.

If a <main> element does not exist, WebFormsJS uses <body>.

This change removes one of the configuration steps that previously had to be recommended to developers.

As a result, the WebFormsJS 2.3 package can now be consumed directly from a CDN without requiring developers to download and host the library themselves.

The package size is approximately 45 KB.

For applications that do not need to customize these locations, the result is a simpler setup with less configuration and a very small client-side payload.

Modal

A dedicated Modal API has also been introduced.

The existing concept is essentially a container or Box, but Modal is the terminology commonly used on the web for this type of UI.

A modal can be opened with:

ShowModal

and removed with:

CloseModal

This provides a clearer high-level API for a very common UI pattern.

What Is Left?

With the release approximately three to four weeks away, the project has moved from architectural design into final implementation and refinement.

The major new foundations are now in place:

Component-scoped execution through BeginComponent
Automatic component boundaries through DoComponent
Declarative collection rendering through RenderList
Form-to-JSON conversion through GetFormJSON
The new Variable system
Improved value handling through SafeValue
Protocol improvements for DeleteAll
WebFormsJS size and configuration improvements
<main>-based default locations with automatic <body> fallback
Page-level protection against stale requests and Action Controls

The remaining work is primarily focused on completing the Variable operations, finalizing request lifecycle handling, integration testing, edge cases, and polishing the APIs before release.

WebForms Core 2.3 is becoming much more than an incremental update.

The component boundary, scoped execution, data binding, variable management, request lifecycle, and client-side execution model are increasingly becoming parts of one coherent system.

And the most important part is that this is still the same WebForms Core philosophy:

The server provides the commands. WebFormsJS executes them on the client.

But with 2.3, those commands can now operate with much stronger boundaries, better lifecycle control, and a more structured component model.

WebForms Core 2.3 is getting close.

WFC in R Programming Language

Elanat Framework — Thu, 22 Oct 2026 13:42:29 +0000

WebForms Core (WFC) is now available for R, bringing server-side UI manipulation and server-orchestrated browser interaction to the R programming language.

WebForms Core is a Server-Driven UI technology built around a stateless server that does not dynamically render the UI. Its output is standard HTML without framework-specific attributes or tags. WebForms Core uses a compact INI-based format for communication between the server and browser and can be implemented in different web programming languages.

The webformscore package provides the R implementation of the WebForms class, allowing R applications to generate WebForms Core commands that are executed in the browser by WebFormsJS.

This makes it possible to build interactive web interfaces in R without creating a separate JavaScript application or manually writing JavaScript for UI behavior.

WebForms Core in R

WebForms Core uses a Commander–Executor architecture:

    R Application
          │
          ▼
    WebForms Class
          │
          │ WebForms Core Commands
          │
          ▼
WebFormsJS Browser Runtime
          │
          ▼
      HTML DOM

In an R application, the WebForms class — provided by the webformscore package — acts as the Commander. It constructs a sequence of WebForms Core commands that describe UI operations and interaction logic.

WebFormsJS runs in the browser as the Executor. It parses those commands and performs the corresponding operations on the HTML DOM.

The R application therefore does not need to directly manipulate the browser DOM with JavaScript. R is responsible for constructing the command sequence, while the browser runtime is responsible for executing it.

This also shows that WebForms Core is not tied to a particular server language. The same architectural concept can be implemented across different programming languages through their corresponding WebForms classes. In R, this allows R to participate directly in server-orchestrated web interfaces without requiring a separate front-end framework or a separate JavaScript application.

Installation

The webformscore package can be installed from CRAN:

install.packages("webformscore")

Then load it in an R application:

library(webformscore)

A web server such as httpuv can be used to expose the R application over HTTP:

library(httpuv)
library(webformscore)

The WebForms class is provided by the webformscore package, while WebFormsJS runs on the client side.

A Digital Clock with WFC

The following example creates a digital clock using R, httpuv, WebForms Core, and WebFormsJS.

The clock updates every second. The time is obtained through WebForms Core date values, formatted on the server-command side, and assigned to the HTML element.

No custom JavaScript is written for the clock.

library(httpuv)
library(webformscore)

html_form <- function() {
'
<!DOCTYPE html>
<html>
<head>
    <title>WebForms Core Technology in R - Digital Clock Example</title>
    <script type="module" src="/script/web-forms.js"></script>

    <style>
        body {
            margin: 0;
            min-height: 100vh;
            display: flex;
            flex-direction: column;
            align-items: center;
            justify-content: center;
            background: #111;
            color: #fff;
            font-family: Arial, sans-serif;
        }

        h1 {
            margin-bottom: 30px;
            font-size: 28px;
            font-weight: normal;
        }

        #Clock {
            padding: 30px 45px;
            border: 2px solid #333;
            border-radius: 12px;
            background: #000;
            color: #00ff66;
            font-family: "Courier New", monospace;
            font-size: 64px;
            font-weight: bold;
            letter-spacing: 6px;
            box-shadow:
                0 0 15px rgba(0, 255, 102, 0.25),
                inset 0 0 20px rgba(0, 255, 102, 0.08);
            text-shadow:
                0 0 5px #00ff66,
                0 0 15px rgba(0, 255, 102, 0.7);
        }
    </style>
</head>
<body>
    <h1>WebForms Core Technology in R</h1>

    <div id="Clock"></div>
</body>
</html>
'
}

app <- list(
    call = function(req) {

        if (req$REQUEST_METHOD == "GET" &&
            req$PATH_INFO == "/script/web-forms.js") {

            return(list(
                status = 200L,
                headers = list(
                    "Content-Type" = "application/javascript; charset=utf-8"
                ),
                body = paste(
                    readLines("script/web-forms.js", warn = FALSE),
                    collapse = "\n"
                )
            ))
        }

        if (req$REQUEST_METHOD == "GET" &&
            req$PATH_INFO == "/") {

            form <- WebForms$new()

            form$add_save_value("clock-format", "{{Hour}}:{{Minute}}:{{Second}}")

            form$replace_save_value("clock-format", "{{Hour}}", Fetch$date_hours)
            form$replace_save_value("clock-format", "{{Minute}}", Fetch$date_minutes)
            form$replace_save_value("clock-format", "{{Second}}", Fetch$date_seconds)
            form$set_format_save_value("clock-format", "(^|:)(\\d)(?=:|$)", "$$10$2")

            form$set_text("Clock", Fetch$save("clock-format"))

            form$delay(1000)
            form$go_to(1, 31536000)

            return(list(
                status = 200L,
                headers = list(
                    "Content-Type" = "text/html; charset=utf-8"
                ),
                body = paste0(
                    html_form(),
                    form$export_to_html_comment()
                )
            ))
        }

        return(list(
            status = 404L,
            headers = list(
                "Content-Type" = "text/plain"
            ),
            body = "Not Found"
        ))
    }
)

server <- startServer(
    "127.0.0.1",
    8080,
    app
)

Screenshot of Digital Clock

Note on the `script/web-forms.js` Path

The script/web-forms.js path is relative to the R session's working directory. Make sure the file is available under this path when the server starts. You can check the working directory with getwd() or change it with setwd().

How It Works

The clock starts by creating a WebForms instance:

form <- WebForms$new()

A temporary saved value is then created for the clock format:

form$add_save_value("clock-format", "{{Hour}}:{{Minute}}:{{Second}}")

The placeholders are replaced using WebForms Core date values:

Fetch$date_hours
Fetch$date_minutes
Fetch$date_seconds

For example:

form$replace_save_value("clock-format", "{{Hour}}", Fetch$date_hours)

The set_format_save_value function applies (regex-based) formatting to the stored value:

form$set_format_save_value("clock-format", "(^|:)(\\d)(?=:|$)", "$$10$2")

The pattern (^|:)(\\d)(?=:|$) matches a single digit that appears either at the beginning of the string or immediately after a :, and is followed by either a : or the end of the string. Group 1 ($1) captures the start or the :, and group 2 ($2) captures the digit itself.

In the replacement string "$$10$2", the double dollar sign $$ escapes the dollar sign so it is not interpreted as direct access to a JavaScript object, such as $document. After this escaping, the replacement effectively becomes $1 + 0 + $2: it keeps the captured delimiter, inserts a literal 0, and then keeps the captured digit. This adds the leading zero required for a conventional digital clock.

For example, when the hour is 7, the result becomes:

while an hour such as 17 remains unchanged:

The resulting value is assigned to the Clock element:

form$set_text("Clock", Fetch$save("clock-format"))

The command sequence then waits for one second:

form$delay(1000)

and continues the execution:

form$go_to(1, 31536000)

WebFormsJS executes these commands in the browser, causing the displayed time to update continuously.

No Manual JavaScript

One of the important aspects of this example is what is not present.

There is no code such as:

setInterval(...)

There is no DOM manipulation such as:

document.getElementById(...)

There is no custom JavaScript clock implementation.

The only JavaScript loaded by the page is the WebFormsJS runtime:

<script type="module" src="/script/web-forms.js"></script>

The behavior of the clock is described through WebForms Core commands generated from R.

This demonstrates the distinction between the application language and the browser runtime.

R describes the behavior.

WebFormsJS executes the behavior.

Installing WebFormsJS

The latest WebFormsJS Executor is available through npm or as a downloadable JavaScript file.

Installation via Package

npm package: webformsjs

npm install webformsjs

Download / Copy the File

Why This Is Interesting for R

R is traditionally associated with statistical computing, data analysis, scientific computing, and research applications.

With WebForms Core, R can also be used to construct interactive browser interfaces using the same server-orchestrated UI model.

This can be useful for applications such as:

Data analysis interfaces
Scientific dashboards
Research tools
Interactive reports
Internal applications
Data-driven forms
Administrative interfaces
Real-time UI experiments
Browser-based R applications

The important point is that the browser does not need to be treated as a completely separate application.

The server can orchestrate the interface through WebForms Core commands.

Conclusion

The digital clock is a small example, but it demonstrates an important capability: R can be used to construct browser UI behavior through WebForms Core without manually programming the browser in JavaScript.

The application uses R and the webformscore package to create the commands, while WebFormsJS provides the browser-side runtime that executes them.

R → WebForms → Commands → WebFormsJS → HTML DOM

This opens the door to using R not only as a data and computation language, but also as a server-side Commander for interactive web interfaces.

WebForms Core 2.3 Will Be Released in November 2026

Elanat Framework — Sat, 17 Oct 2026 14:14:00 +0000

WebForms Core 2.3 is currently under development, introducing improvements to component-based development, resource lifecycle management, request handling, state management, and client-side execution.

Component System & Scope

The new component system is one of the major architectural additions planned for WebForms Core 2.3. It is being developed to bring the benefits of component-based development to WebForms Core's distinctive architecture, which uses server-driven commands, client-side execution, and a stateless server without server-side UI rendering.

The component system is designed to provide the following capabilities:

Reusability — Create a component once and reuse it in multiple places across an application.
Component Isolation — Keep each component instance's DOM operations and event handling within its own scope, preventing multiple instances of the same component from interfering with one another.
Separation of Concerns — Organize application functionality into independent components, making code easier to maintain and extend.
Composability — Combine individual components to build more complex user interfaces.
Independent Component State — Allow each component instance to maintain its own state without unintentionally affecting other instances.
Scoped Event Handling — Execute component events and their associated Action Controls within the appropriate component scope.
Parameter-Based Communication — Support passing data and configuration between components.
Event-Based Communication — Allow components to communicate through events and respond to interactions with other components.
Testability — Make individual components easier to test by keeping their behavior and responsibilities organized within defined boundaries.

The goal is to make components reusable, independent, and easier to manage while preserving the existing WebForms Core execution model.

Example: A Counter Component in Blazor Server

The following example demonstrates the concept of independent component instances in Blazor Server. Keep it in mind until WebForms Core 2.3 is released to better understand the component-based approach being developed for WebForms Core.

File: Components/Counter.razor

<h3>Counter: @count</h3>

<button class="btn btn-primary" @onclick="Increment">
    Increment
</button>

@code {
    private int count = 0;

    private void Increment()
    {
        count++;
    }
}

This component contains markup, state, and event-handling logic.

File: Components/Pages/Home.razor

@page "/"

<h1>Home Page</h1>

<Counter />
<Counter />
<Counter />

By placing <Counter /> three times, Blazor creates three independent component instances. Each instance maintains its own count value.

This example illustrates the concept of component reuse and instance isolation. WebForms Core 2.3 is being developed to bring comparable component-oriented benefits to a different architecture, where the server sends commands and WebFormsJS executes them on the client.

EnableAutoCleanup

EnableAutoCleanup is a new method being developed to simplify resource lifecycle management.

When enabled, resources associated with the current page can be registered for cleanup and released when the page changes. These resources may include Event Listeners, Timers, Custom Events, Snapshots, Cache entries, Save data, IndexedDB data, and other resources that are no longer needed.

The purpose is to reduce manual cleanup work and help prevent obsolete resources and event handlers from remaining active after navigation.

Request & Action Control Lifecycle Management

Request handling and Action Control execution are being improved to prevent outdated operations from affecting the current page.

When users trigger multiple operations in quick succession, an earlier request may return after a newer request has already changed the page state. WebForms Core 2.3 is being developed to identify such obsolete requests and prevent their responses or associated Action Controls from executing when they no longer belong to the current page state.

This includes improved handling of request ordering, stale responses, and Action Controls associated with previous page states.

Rendered Value Mirroring

A new structure for mirroring rendered values into Cache and Save is being developed.

The mechanism is designed to compare a stored snapshot with the current outerHTML, identify relevant changes, and represent changed values in a suitable key-value structure. This can provide a consistent basis for retrieving and updating preserved data.

RunWebForms

A new RunWebForms method has been added to execute Action Controls on the client side programmatically.

This provides an additional way to run WebForms Core instructions without relying exclusively on their automatic execution through the usual processing flow.

SetResponse

A new SetResponse method has been added to programmatically add HTML, Action Controls, and other data to a response.

It also supports scenarios in which HTML comments contain WebForms Core instructions that need to be processed on the client side.

Hash URL State Management

State management for URLs containing hashes has been improved to provide more consistent behavior when navigating between hash-based locations.

Transient DOM Improvements

An issue that could cause an execution loop when Transient DOM was used on elements containing Comment Action Controls has been resolved.

Loader Improvements

Loader behavior has been improved with new configuration options for controlling Loader animations, including situations in which data arrives quickly.

The default Loader animation behavior has also been adjusted for CommentBack, with additional configuration options for WasmBack and FrontBack.

SPALink Improvements

SPALink behavior has been improved to allow its settings to be restored to their initial state when required.

Native Form Behavior

The behavior of button and input elements with type="submit" has been aligned more closely with the browser's default form behavior.

An issue that could cause an additional null value to be submitted when an element did not have a name attribute has also been resolved.

Overall Direction

WebForms Core 2.3 continues to build on the Commander-Executor architecture, in which the server provides commands and WebFormsJS executes them on the client.

The planned component system aims to combine reusable UI structures, scoped DOM operations, isolated component instances, and component communication with this architecture. Alongside EnableAutoCleanup, improved request lifecycle management, and state preservation, these developments are intended to make WebForms Core applications easier to organize and maintain without requiring server-side UI rendering.

CodeBehind Is About 19% Faster Than ASP.NET MVC in the Latest Benchmark

Elanat Framework — Fri, 16 Oct 2026 20:59:25 +0000

CodeBehind 4.8, the server-side web framework developed by Elanat, has reached a significant performance milestone in the latest Web Frameworks Benchmark.

According to the benchmark results published on October 6, 2026, CodeBehind 4.8 processes substantially more requests per second than ASP.NET MVC 10 across all three tested request sizes.

The benchmark comparison is available on the Web Frameworks Benchmark results page for C#, where you can review CodeBehind 4.8 alongside ASP.NET MVC and other C# web frameworks.

On average, CodeBehind is about 19% faster than ASP.NET MVC in these results.

Benchmark Results

The benchmark reports the following results for C# frameworks:

Framework	Requests/s (64)	Requests/s (256)	Requests/s (512)
ASP.NET Minimal API	166,518	147,805	143,096
Carter	166,262	146,862	141,774
CodeBehind 4.8	139,431	127,252	126,435
FastEndpoints	135,409	125,525	123,542
ASP.NET MVC 10	114,011	108,498	107,883
Effinitive Framework	107,160	103,343	103,860
GenHTTP	101,527	95,798	98,406
Simplify.Web	56,881	57,221	56,785

The direct comparison between CodeBehind and ASP.NET MVC is particularly interesting:

Request Size	CodeBehind 4.8	ASP.NET MVC 10	CodeBehind Advantage
64	139,431	114,011	22.3%
256	127,252	108,498	17.3%
512	126,435	107,883	17.2%

Taking the three comparisons together, CodeBehind's average advantage is approximately 19%.

This comparison is particularly significant because CodeBehind is a versatile, feature-rich web framework capable of supporting different development models and architectural approaches. It can provide MVC, MVC First-View, WebForms Core, and other approaches to server-side web development, making it comparable in scope to Microsoft's three major .NET web frameworks: ASP.NET Core MVC, Razor Pages, and Blazor. Through its integration with WebForms Core, CodeBehind also supports server-orchestrated UI manipulation using WebForms commands and WebFormsJS, with features such as Render, Snapshot, Rollback, and TransientDom. Achieving approximately 19% higher average throughput than ASP.NET MVC in the reported benchmark is particularly noteworthy given the versatility and range of capabilities CodeBehind offers.

An Important Detail About the CodeBehind Execution Model

CodeBehind uses a code-generation and compilation process to prepare its View and Controller execution paths. During initial startup, or after relevant structural changes, it generates a C# source file containing a switch statement for route handling and dedicated asynchronous methods for individual Views and Controllers. It then compiles this generated source code and loads the resulting assembly.

For example, a route such as /series/Default.aspx can be mapped to a dedicated method such as _series_Default_aspx_SeriesSiteController_PageLoad1. Once compilation is complete, request handling uses the generated, compiled execution paths instead of regenerating and recompiling this code for every request. This process is triggered again when required by application restarts, redeployment, or structural changes to Views and Controllers. With precompilation, the generation and compilation cost can also be moved to the build or deployment stage.

This distinction is important when interpreting performance benchmarks: the initial code-generation and compilation cost is separate from steady-state request throughput. Whether it affects a particular benchmark depends on how that benchmark measures application startup and request processing. The reported results establish CodeBehind's approximately 19% average throughput advantage over ASP.NET MVC in the three tested scenarios.

This Performance Did Not Come From a Single Change

The performance gap is the result of continuous engineering work by Elanat.

CodeBehind has been developed with a strong focus on reducing unnecessary processing in the server-side request pipeline while maintaining a structured programming model for server-side web applications.

Recent releases have introduced several important architectural and implementation improvements.

Removing Unnecessary Processing

One example is the removal of the Control method in CodeBehind 4.8.

Although the overhead of this method was relatively small, it introduced additional processing during requests. Removing it eliminates that unnecessary path from the framework.

This is an important principle in performance-oriented framework development:

Small amounts of unnecessary work become significant when they are repeated across a large number of requests.

CodeBehind 4.8 also removed the web_forms_view_place and use_comment_mode_for_web_forms_combinate options as part of a cleaner and more reliable options architecture.

These changes are not simply API cleanup. They reduce legacy paths and simplify framework behavior.

Performance Through Simplification

Elanat has also been working toward a more consistent WebForms API across different programming languages.

The WebForms class is available across multiple WebForms Core implementations. Removing language-specific behavior such as the old Control pattern makes the API more consistent between implementations.

This is useful not only from an API-design perspective but also from a maintenance and optimization perspective.

A smaller and more consistent execution path is easier to optimize.

CodeBehind and ASP.NET MVC

ASP.NET MVC remains one of the most established server-side web frameworks in the .NET ecosystem.

The benchmark result does not mean that CodeBehind is faster than MVC in every possible application or workload. Real-world performance depends on application architecture, middleware, database access, serialization, network conditions, hardware, configuration, and the specific operations performed by an application.

However, the benchmark provides a useful direct comparison under the same reported benchmark environment.

In these results, CodeBehind consistently stays ahead of ASP.NET MVC:

139,431 vs. 114,011 requests/s at the 64-request test size,

127,252 vs. 108,498 requests/s at 256,

and

126,435 vs. 107,883 requests/s at 512.

The resulting average advantage is approximately 19%.

More Than a Benchmark Number

For Elanat, the significance of this result is not simply the number itself.

CodeBehind has been evolving through a series of architectural decisions aimed at reducing unnecessary work, simplifying execution paths, improving rendering behavior, and creating a more consistent server-side development model.

The performance result is therefore better viewed as the outcome of continued optimization rather than a single performance trick.

Conclusion

The latest Web Frameworks Benchmark shows that CodeBehind 4.8 is approximately 19% faster than ASP.NET MVC 10 on average across the three reported request sizes.

The individual advantage ranges from 17.2% to 22.3%, with CodeBehind outperforming ASP.NET MVC in every tested case.

At the same time, CodeBehind performs one-time View and Controller class generation and compilation during its initial execution. This additional work should be distinguished from steady-state request processing after compilation.

Building a Bubble Popping Game with WebForms Core + Online Demo

Elanat Framework — Thu, 15 Oct 2026 13:12:07 +0000

WebForms Core (WFC) is a server-side UI manipulation technology that lets developers control HTML elements and handle browser events through commands generated on the server. In this tutorial, we will use WebForms Core with C# and CodeBehind to build a simple bubble popping game.

Live demo: Bubble Popping Game

The game demonstrates how to create HTML elements dynamically, attach events, update the score, run intervals, and detect when an element exceeds a specified width, all through WebForms Core commands.

WebForms Core is a technology developed by Elanat and is available in 18 programming languages.

Note: WebForms Core can be used to build simple to moderately complex games, including animated games and logic-based games such as Memory. For large or highly complex games, specialized technologies and tools, such as WebGL, WebGPU, and dedicated game engines, are recommended.

1. Defining the Game Interface

The page contains a game area, a score counter, a speed counter, a message for the end of the game, and a button to start a new game.

<div id="GameArea"></div>
<br />

<b id="Points">Points: <span>0</span></b>
<b id="Speed">Speed: <span>5</span></b>
<b id="Finall"></b>

<input id="PointsValue" type="hidden" value="0">
<input id="SpeedValue" type="hidden" value="5">
<input id="Start" type="button" value="Start New">

The GameArea element is the main container for the bubbles. The Points and Speed elements display the current game values, while the hidden inputs store those values so that WebForms Core commands can read and update them.

The Start button restarts the game, and Finall displays the player's final score when the game ends.

Styling the bubbles

CSS gives the game its visual appearance. The game area uses a light blue background, while each bubble is a green circle with white curved lines to create a three-dimensional appearance.

#GameArea {
    width: 1280px;
    height: 720px;
    background-color: lightblue;
    overflow-x: auto;
    white-space: nowrap;
    display: inline-block;
}

.bubblebox {
    width: 100%;
    height: 100px;
}

.bubble {
    width: 100px;
    height: 100px;
    background-color: #c9e83b;
    border-radius: 50%;
    box-shadow: -10px 0px 10px rgba(0, 0, 0, 0.3);
    float: left;
    position: relative;
    overflow: hidden;
}

.pusher {
    width: 100px;
    height: 100px;
    float: left;
}

The .bubblebox class represents a row containing a pusher and a bubble. The .pusher element occupies space before the bubble, allowing the bubble's horizontal position to change as the pusher grows.

The remaining CSS uses ::before and ::after pseudo-elements to draw decorative curves inside each bubble. Attribute selectors such as [bubblerow="1"] assign different top margins to different rows.

2. Initializing WebForms Core

The main controller is BubblePoppingGameController, which inherits from CodeBehindController.

using CodeBehind;

public partial class BubblePoppingGameController
    : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEventListener(
            "GameArea", "mutationobserver", "end");

        form.SetCommentEvent(
            "Start", HtmlEvent.OnClick, "start");

        // Game commands are defined here.
    }
}

The WebForms class is used to define the commands that control the game.

Two event configurations are especially important:

SetCommentEventListener registers a MutationObserver-based listener for changes in GameArea. The listener invokes the end command index when the configured event condition is met.
SetCommentEvent associates the button's click event with the start command index.

The controller then defines the command sequences for starting, playing, and ending the game. WebForms Core exports these commands as HTML comments, which WebFormsJS processes in the browser.

This approach allows the developer to define UI operations and event handling in C# without manually writing JavaScript for each interaction.

3. Starting a New Game

The start command index initializes the game:

form.StartIndex("start");

form.AppendForm(Reset());

form.SetText("Finall", "");
form.SetValue("PointsValue", "0");
form.SetText(
    "Points|<span>",
    Fetch.GetValue("PointsValue"));

form.SetValue("SpeedValue", "5");
form.SetText(
    "Speed|<span>",
    Fetch.GetValue("SpeedValue"));

form.AppendForm(Initialization());

form.IncreaseWidth("{pusher}-1", 5);
form.AssignInterval(100, "pusher");

Each operation has a specific purpose.

First, Reset() removes the existing game elements and stops the intervals from the previous game. The final-score message is cleared, and the score and speed values are restored to their initial values.

Fetch.GetValue() reads the value of a hidden input. The result is then used by SetText() to update the corresponding display.

Next, Initialization() creates the first row and its bubble.

Finally, IncreaseWidth() increases the width of the pusher, and AssignInterval() schedules repeated execution of the command associated with the pusher index.

This is an important characteristic of WebForms Core: an interval can repeatedly execute a sequence of UI commands without requiring a custom JavaScript timer for the game logic.

4. Creating Bubbles Dynamically

The Initialization() method defines the structure of a bubble row.

private WebForms Initialization()
{
    WebForms form = new WebForms();

    form.AddTag("GameArea", "div");

    form.SetClass(
        "GameArea|<div>-1", "bubblebox");

    form.SetAttribute(
        "{bubblebox}-1",
        "bubblerow",
        Fetch.Random(1, 8));

    form.AddTag("{bubblebox}-1", "div");
    form.SetClass(
        "{bubblebox}-1|<div>-1", "pusher");

    form.AddTag("{bubblebox}-1", "div");
    form.SetClass(
        "{bubblebox}-1|<div>-1", "bubble");

    form.SetCommentEvent(
        "{bubble}-1",
        HtmlEvent.OnMouseEnter,
        "popping");

    // Movement and overflow detection follow.

    return form;
}

The method creates three elements:

A bubblebox container inside GameArea.
A pusher element inside the container.
A bubble element beside the pusher.

SetClass() assigns the CSS classes, while SetAttribute() adds a bubblerow attribute. Fetch.Random(1, 8) supplies the row number used to determine the bubble's vertical placement.

The last command associates the bubble's mouseover-style event, HtmlEvent.OnMouseEnter, with the popping command index.

When the pointer enters a bubble, WebForms Core can therefore execute the commands defined under popping.

The important point is that the bubble elements are created dynamically. They do not need to be written individually into the original HTML page.

5. Moving the Bubble

The pusher controls the bubble's horizontal position. Its width increases over time, making the bubble move across the game area.

form.IncreaseWidth("{pusher}-1", 1);
form.AssignInterval(10, "pusher-pluse");

The pusher-pluse command index increases the pusher's width by one unit. The interval is assigned a delay of 10 milliseconds.

When the game starts, the pusher index is also assigned a 100-millisecond interval:

form.IncreaseWidth("{pusher}-1", 5);
form.AssignInterval(100, "pusher");

These two intervals perform different roles: pusher-pluse controls the continuous growth of the pusher, while pusher is the separate interval configured during game initialization.

The game also needs to detect when the pusher grows too large. WebForms Core provides a custom DOM event for this purpose.

form.CreateCustomDOMEvent(
    "{pusher}-1",
    "widthOverflow",
    "style",
    "width",
    "greater",
    "1100",
    "",
    true,
    200);

form.SetCommentEventListener(
    "{pusher}-1",
    "widthOverflow",
    "end");

The custom event monitors the pusher's width style and checks whether it exceeds 1100. Its configuration also includes the event options true and 200.

When widthOverflow occurs, the listener invokes the end command index. This connects the movement logic to the end-of-game logic without requiring a manually written JavaScript event handler.

6. Popping a Bubble and Updating the Score

The popping command index defines what happens when the player touches a bubble.

form.StartIndex("popping");

form.IncreaseValue("PointsValue", 1);
form.SetText(
    "Points|<span>",
    Fetch.GetValue("PointsValue"));

form.IncreaseValue("SpeedValue", 1);
form.SetText(
    "Speed|<span>",
    Fetch.GetValue("SpeedValue"));

form.Delete("$/");
form.AppendForm(Initialization());

First, IncreaseValue() increments the score stored in PointsValue. Fetch.GetValue() retrieves the updated value, and SetText() refreshes the score shown on the page.

The speed value is updated in the same way. Each successful bubble interaction increases it by one and refreshes the display.

The command Delete("$/") removes the element selected by that input-place expression. The game then calls Initialization() again, creating another bubble row.

Consequently, a successful interaction updates the counters, removes the targeted element, and creates another bubble. The player can continue interacting with bubbles until the overflow event ends the game.

In this implementation, the speed counter is incremented as a displayed value, but the interval delays themselves remain fixed at 100 and 10 milliseconds.

7. Ending the Game

When the overflow listener invokes the end command index, the controller displays the final score and resets the game elements.

form.StartIndex("end");

form.SetText(
    "Finall",
    "@:Your point is: " +
    form.Inject(
        Fetch.GetText("Points|<span>")));

form.AppendForm(Reset());

Fetch.GetText() reads the displayed score, and Inject() inserts the retrieved text into the command being constructed.

SetText() then displays the final-score message inside Finall. The Reset() method removes the game elements and stops the intervals.

The reset method is defined as follows:

private WebForms Reset()
{
    WebForms form = new WebForms();

    form.ElementExists("GameArea|<div>");
    form.Delete("GameArea|<div>");

    form.DeleteInterval("pusher");
    form.DeleteInterval("pusher-pluse");

    return form;
}

The element-existence check precedes the deletion of the game rows. The method also removes both named intervals, preventing the previous game's movement commands from continuing after a restart or game end.

The Start New button can then execute the start command index to initialize a fresh game.

8. Exporting the Commands

At the end of PageLoad(), the controller exports the commands:

Write(form.ExportToHtmlComment());

This writes the WebForms Core command representation as HTML comments in the response.

WebFormsJS processes these comments in the browser and executes the corresponding operations against the actual HTML DOM. The server defines the command sequences, while the client executes them.

The result is a game whose interface is built and manipulated through WebForms Core rather than through a collection of hand-written JavaScript DOM operations.

Screenshot of Bubble Popping Game

Conclusion

The Bubble Popping Game demonstrates several practical WebForms Core capabilities in a single example:

Dynamically creating HTML elements and assigning CSS classes and attributes.
Connecting browser events to named command indexes.
Updating values and displayed text.
Executing repeated commands through intervals.
Detecting DOM conditions through custom events.
Removing elements, stopping intervals, and restarting the game.

These features make it possible to implement interactive browser experiences using C# and WebForms Core, with WebFormsJS executing the generated commands in the browser.

Try the game: Open the Bubble Popping Game demo

CSRF Protection in WebForms Core Using CodeBehind

Elanat Framework — Sat, 10 Oct 2026 16:03:18 +0000

1. Introduction to CSRF Protection in WebForms Core

Cross-Site Request Forgery (CSRF) is a web security vulnerability in which an attacker tricks a user's browser into sending an unwanted request to a website where the user is authenticated. If the website relies on automatically attached authentication cookies without properly verifying the request, an attacker may be able to trigger actions on behalf of the victim.

WebForms Core (WFC), introduced by Elanat, provides a server-oriented approach to web interface manipulation. The backend generates commands that WebFormsJS executes in the browser, allowing web interfaces to be manipulated through server-generated instructions without requiring a separate frontend framework.

In this article, we will implement a basic CSRF protection mechanism using WebForms Core and CodeBehind, a backend web framework developed by Elanat. We will generate a secure token, store it in a session, add it to an HTML form, and validate it when the form is submitted.

2. CodeBehind as the Backend

CodeBehind handles HTTP requests, manages the session-based CSRF token, validates submitted data, and generates responses through WebForms Core.

The process follows this sequence:

The browser requests the page.
CodeBehind retrieves an existing CSRF token from the session or generates a new one.
WebForms Core adds the token to the HTML form as a hidden input.
The browser submits the form with the token.
CodeBehind compares the submitted token with the token stored in the session.
WebForms Core generates commands to display the validation result.

The security decision takes place on the backend. WebFormsJS executes the resulting interface commands, but it does not determine whether the CSRF token is valid.

3. Generating a Secure CSRF Token

A CSRF token must be unpredictable so that an attacker cannot easily construct a valid request. C# provides RandomNumberGenerator, which is designed for cryptographically secure random number generation.

The following code generates a token from 32 random bytes and converts it into a hexadecimal string:

using System.Security.Cryptography;

string token = Convert.ToHexString(
    RandomNumberGenerator.GetBytes(32));

This produces a 64-character hexadecimal token representing 256 bits of random data.

Unlike a token generated with the ordinary Random class, this value is suitable for security-sensitive purposes. The token should be generated on the server and must not be predictable from public information such as usernames, timestamps, or sequential identifiers.

4. Storing the Token in Session

The token must remain available between the initial page request and the subsequent form submission. In this example, ASP.NET Core Session provides the required storage.

The following method retrieves the existing token or generates and stores one if it does not exist:

private string GetCsrfToken(HttpContext context)
{
    string token = context.Session.GetString("csrf_token");

    if (string.IsNullOrEmpty(token))
    {
        token = Convert.ToHexString(
            RandomNumberGenerator.GetBytes(32));

        context.Session.SetString("csrf_token", token);
    }

    return token;
}

The session allows the server to associate the token with the user's session and retrieve it when the form is submitted. Session services and middleware must be configured correctly in the ASP.NET Core application.

The session cookie should also be protected with appropriate security settings, including HTTPS and suitable cookie attributes.

5. Adding the Token to the HTML Form with WebForms Core

The CSRF token is included in the form as a hidden input. WebForms Core can generate the required interface command without requiring a separate JavaScript operation to create the field.

The example form is:

<form method="POST" action="/security_csrf">
    <label for="email">Email: </label>
    <input type="text" name="email" id="email" />
    <br />
    <button type="submit">Update Email</button>
</form>

In the CodeBehind controller, the token is added to the form using WebForms Core:

WebForms form = new WebForms();

form.AddHidden("<form>", "csrf_token", csrfToken);

Write(form.ExportToHtmlComment());

AddHidden targets the form and adds a hidden field named csrf_token. ExportToHtmlComment() exports the WebForms Core commands in the format expected by the client-side executor.

To execute WebForms Core commands in the browser, the page must also include the WebFormsJS client-side library. For example, if the library is located at /script/web-forms.js, add the following script to the HTML document's <head>:

<script type="module" src="/script/web-forms.js"></script>

Adjust the script path to match the location of the WebFormsJS file in your application.

The browser submits the hidden token along with the other form fields. Although the token is not visible in the interface, it is accessible to the page and must not be treated as a secret from JavaScript executing in that page. Its security depends on its unpredictability and server-side validation, not on the hidden field itself.

Full page management code

public void PageLoad(HttpContext context)
{
    string csrfToken = GetCsrfToken(context);

    if (context.Request.Method == "POST")
    {
        Button_Click(context, csrfToken);
        return;
    }

    WebForms form = new WebForms();

    form.AddHidden("<form>", "csrf_token", csrfToken);

    Write(form.ExportToHtmlComment());
}

6. Validating CSRF Tokens on POST Requests

When the form is submitted, CodeBehind retrieves the token from the request and compares it with the token stored in the session.

The following example checks that both values are non-empty before comparing them:

string formToken =
    context.Request.Form["csrf_token"].ToString();

if (!string.IsNullOrEmpty(csrfToken) &&
    !string.IsNullOrEmpty(formToken) &&
    formToken == csrfToken)
{
    // Continue with the protected operation.
}
else
{
    // Reject the protected operation.
}

Checking both values is important. If the session token is missing or the submitted form does not contain a token, the request must not be accepted.

The == comparison makes the basic validation logic easy to understand. For applications requiring stronger protection against timing-based comparison attacks, a fixed-time comparison can be used instead, as discussed in the final section.

A successful comparison means that the request contains the expected session token. It does not replace authentication, authorization, or validation of the submitted email address.

7. Handling Validation Results with WebForms Core

After validating the token, the controller uses WebForms Core to generate a response that communicates the result to the user.

private void Button_Click(HttpContext context, string csrfToken)
{
    string formToken =
        context.Request.Form["csrf_token"].ToString();

    string email =
        context.Request.Form["email"].ToString();

    WebForms form = new WebForms();

    if (!string.IsNullOrEmpty(csrfToken) &&
        !string.IsNullOrEmpty(formToken) &&
        formToken == csrfToken)
    {
        form.Message(
            "CSRF token validation succeeded.",
            "success");

        form.Message(
            "Your Email is: " + new Security().SafeValue(email));
    }
    else
    {
        form.Message(
            "Security check failed. Please refresh the page and try again.",
            "warning");
    }

    IgnoreAll(); // Transition by bypassing View and Layout
    Write(form.Response());
}

The example uses new Security().SafeValue(email) before including the submitted email in a message. This is intended to prevent untrusted email content from injecting executable HTML or script content into the interface. It is important to use the appropriate output-safety method for the rendering context and avoid encoding the same content twice.

Message generates the interface feedback, while Response() generates the WebForms Core response. IgnoreAll() bypasses the view and layout for this response, allowing the command response to be returned directly.

This demonstrates the separation between security decisions and interface updates: CodeBehind validates the request on the server, WebForms Core generates the commands, and WebFormsJS executes them in the browser.

The application does not have to return an HTTP 403 status solely to display a validation warning. In this command-response workflow, a normal response can preserve Action Control execution. The essential requirement is that the protected operation must never run when validation fails.

8. Additional Security Layers and Conclusion

A session-based CSRF token is an important protection, but it should be part of a broader security strategy.

Fixed-time token comparison

For additional protection, the simple == comparison can be replaced with CryptographicOperations.FixedTimeEquals. This method compares equal-length byte arrays in a way designed to reduce information leakage through timing differences.

For example:

private bool FixedTimeEquals(string a, string b)
{
    if (string.IsNullOrEmpty(a) ||
        string.IsNullOrEmpty(b))
        return false;

    byte[] aBytes = System.Text.Encoding.UTF8.GetBytes(a);
    byte[] bBytes = System.Text.Encoding.UTF8.GetBytes(b);

    if (aBytes.Length != bBytes.Length)
        return false;

    return CryptographicOperations.FixedTimeEquals(
        aBytes, bBytes);
}

The empty-value checks ensure that two missing tokens are never treated as a successful match. The length check ensures that the comparison receives byte arrays of equal length.

Other security measures

Depending on the application, additional measures can include:

Origin validation: Check the Origin header against the expected origin for state-changing requests. A carefully implemented Referer check can be used as a fallback when appropriate.
SameSite cookies: Configure authentication cookies with an appropriate SameSite policy, such as Lax or Strict, according to the application's requirements.
HTTPS: Protect session cookies and requests in transit using HTTPS and suitable secure-cookie settings.
Authentication and authorization: Verify that the user is authenticated and permitted to perform the requested operation.
Input validation and output safety: Validate submitted data and use Security.SafeValue or another appropriate context-specific output-encoding mechanism when displaying untrusted content.

These measures complement one another. Origin validation and SameSite cookies provide additional layers of defense, but they should not automatically be treated as replacements for CSRF token validation where it is required.

With CodeBehind handling the backend logic and WebForms Core managing server-generated interface commands, CSRF protection fits naturally into a server-oriented web application. The security decision remains on the server, while the resulting feedback is delivered through the WebForms Core response mechanism.

Drag and Drop Without Writing JavaScript with WFC + Online Demo

Elanat Framework — Thu, 08 Oct 2026 12:43:58 +0000

Drag and Drop interactions are usually implemented with client-side JavaScript. Developers typically need to listen for pointer events, track the dragged element, prevent default browser behavior, update CSS classes, and finally move or remove the element.

With WebForms Core (WFC), the same interaction can be implemented by defining events and commands on the server. No custom JavaScript event handlers are required.

The following example uses Node.js and Express.

It is recommended to view the drag-and-drop demo before looking at the code.

webforms-core.github.io

The Example

The page contains two zones:

dragZone contains draggable elements.
dropZone is the destination.

When an item is dragged with a mouse, it can be moved between the two zones. On touch devices, where native HTML Drag and Drop is not normally suitable, a direct tap can be used to move an item between the zones.

const express = require('express');
const { WebForms, HtmlEvent, Fetch } = require('./WebForms');

const app = express();
const PORT = 3000;

app.use(express.static('public'));

app.get('/', (req, res) => {
    const form = new WebForms();

    form.setCommentEvent("dragZone|<div>*", HtmlEvent.OnDragStart, "drag-start");
    form.setCommentEvent("-", HtmlEvent.OnDragEnd, "drag-end");

    form.setPreventDefaultEvent("dragZone", HtmlEvent.OnDragOver);
    form.setCommentEvent("-", HtmlEvent.OnDragOver, "drag-over-back");
    form.setCommentEvent("-", HtmlEvent.OnDragLeave, "drag-leave-back");
    form.setCommentEvent("-", HtmlEvent.OnDrop, "drop-back");

    form.setPreventDefaultEvent("dropZone", HtmlEvent.OnDragOver);
    form.setCommentEvent("-", HtmlEvent.OnDragOver, "drag-over");
    form.setCommentEvent("-", HtmlEvent.OnDragLeave, "drag-leave");
    form.setCommentEvent("-", HtmlEvent.OnDrop, "drop");

    form.setCommentEvent("dragZone|<div>*", HtmlEvent.OnTouchStart, "touch-start");

    form.startIndex("drag-start");
    form.saveOuterText("$");
    form.saveId("$", "id");

    form.startIndex("drag-end");
    form.deleteClass("$", "hide");
    form.assignDelay(100);

    form.startIndex("drag-over");
    form.insertClass("dropZone", "highlight");

    form.startIndex("drag-leave");
    form.deleteClass("dropZone", "highlight");

    form.startIndex("drop");
    form.delete(Fetch.save("id"));
    form.addText("dropZone", Fetch.save());

    form.startIndex("drag-over-back");
    form.insertClass("dragZone", "highlight");

    form.startIndex("drag-leave-back");
    form.deleteClass("dragZone", "highlight");

    form.startIndex("drop-back");
    form.delete(Fetch.save("id"));
    form.addText("dragZone", Fetch.save());

    form.startIndex("touch-start");
    form.elementExists("dragZone|{{id}}");
    form.assignReplace("{{id}}", Fetch.getId("$"));
    form.addText("dropZone", Fetch.getOuterText("$"));
    form.else();
    form.addText("dragZone", Fetch.getOuterText("$"));
    form.delete("$");

    res.send(`
        <!DOCTYPE html>
        <html>
        <head>
          <title>Drag and Drop - WebForms Core</title>
          <script type="module" src="/script/web-forms.js"></script>

          <style>
            #dropZone, #dragZone {
                width: 100%;
                max-width: 600px;
                height: auto;
                min-height: 200px;
                border: 2px dashed #ccc;
                border-radius: 5px;
                text-align: center;
                padding: 20px;
                margin: 20px auto;
            }

            #dropZone.highlight, #dragZone.highlight {
                border-color: #4CAF50;
                background-color: #f8f8f8;
            }

            .dragitem {
                width: 100px;
                height: 100px;
                background-color: #4CAF50;
                color: white;
                text-align: center;
                line-height: 100px;
                cursor: move;
                margin: 20px auto;
            }

            .hide {
                display: none;
            }
          </style>
        </head>

        <body>
            <h2>Drag and Drop</h2>

            <blockquote>
                With a mouse, items are moved via drag and drop;
                with touch, they are moved by a direct tap.
            </blockquote>

            <div id="dragZone">
                <div class="dragitem" id="dragitem1" draggable="true">Drag me! 1</div>
                <div class="dragitem" id="dragitem2" draggable="true">Drag me! 2</div>
                <div class="dragitem" id="dragitem3" draggable="true">Drag me! 3</div>
                <div class="dragitem" id="dragitem4" draggable="true">Drag me! 4</div>
            </div>

            <div id="dropZone">Drop here</div>

            ${form.exportToHtmlComment()}
        </body>
        </html>
    `);
});

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:3000`);
});

Defining the Drag Events

The first step is to associate WebForms Core events with the draggable elements.

form.setCommentEvent(
    "dragZone|<div>*",
    HtmlEvent.OnDragStart,
    "drag-start"
);

form.setCommentEvent(
    "-",
    HtmlEvent.OnDragEnd,
    "drag-end"
);

The selector:

dragZone|<div>*

targets the div elements inside dragZone. Each of these elements can therefore participate in the same drag behavior.

The - input place refers to the event target, allowing the same command sequence to operate on the element that triggered the event.

Saving the Dragged Element

When dragging starts, the example stores two pieces of information:

form.startIndex("drag-start");
form.saveOuterText("$");
form.saveId("$", "id");

The outer text is saved so it can later be inserted into another zone, while the element's ID is saved as id.

This is important because the server-generated commands can later use the saved values without requiring custom client-side JavaScript variables.

Highlighting the Drop Zone

While the user is dragging an item over the destination, the destination receives a visual highlight:

form.startIndex("drag-over");
form.insertClass("dropZone", "highlight");

When the pointer leaves the zone, the class is removed:

form.startIndex("drag-leave");
form.deleteClass("dropZone", "highlight");

The same mechanism is used for the original dragZone.

This means the visual state is controlled through WebForms Core commands rather than through a JavaScript event handler.

Moving the Item

The actual drop operation is particularly simple:

form.startIndex("drop");
form.delete(Fetch.save("id"));
form.addText("dropZone", Fetch.save());

The sequence performs two operations:

Remove the original element using its saved ID.
Add its saved content to dropZone.

The important point is that these are DOM manipulation commands generated by the server-side WebForms class. There is no client-side dragstart, dragover, or drop function written by the developer.

Supporting the Reverse Direction

The same mechanism works when moving an element back from dropZone to dragZone.

form.startIndex("drop-back");
form.delete(Fetch.save("id"));
form.addText("dragZone", Fetch.save());

The destination changes, but the basic operation remains the same:

Delete original element → Add its content to destination

Touch Interaction Without JavaScript

Native HTML Drag and Drop is primarily designed around pointer-based dragging and is not a reliable interaction model for touch devices.

Instead of implementing a separate JavaScript touch system, this example defines a WebForms Core OnTouchStart event:

form.setCommentEvent(
    "dragZone|<div>*",
    HtmlEvent.OnTouchStart,
    "touch-start"
);

The touch behavior is then implemented with WebForms Core commands:

form.startIndex("touch-start");

form.elementExists("dragZone|{{id}}");
form.assignReplace("{{id}}", Fetch.getId("$"));

form.addText("dropZone", Fetch.getOuterText("$"));

form.else();

form.addText("dragZone", Fetch.getOuterText("$"));
form.delete("$");

Screenshot of Drag & Drop Example

The logic is:

If the touched element already exists in dragZone, move it to dropZone.
Otherwise, move it back to dragZone.

In other words, a touch interaction can provide a simple toggle between the two zones without implementing a custom JavaScript drag-and-drop engine.

One Server-Side Definition, Multiple Client Behaviors

The example demonstrates an important aspect of WebForms Core.

The developer describes the interaction on the server:

Event
    ↓
WebForms command sequence
    ↓
WebFormsJS
    ↓
HTML DOM

WebFormsJS executes the commands in the browser. It does not require the developer to write separate JavaScript functions for each event.

The application therefore does not contain code such as:

element.addEventListener("dragstart", ...);
element.addEventListener("dragover", ...);
element.addEventListener("dragleave", ...);
element.addEventListener("drop", ...);
element.addEventListener("touchstart", ...);

Instead, the interaction is declared through the server-side WebForms class.

Why This Is Different

A conventional implementation usually requires the developer to create a client-side interaction layer:

HTML
  ↓
JavaScript event handlers
  ↓
Application state
  ↓
DOM manipulation

With WebForms Core, the interaction can be expressed as server-defined commands:

Server
  ↓
WebForms
  ↓
WebForms Core commands
  ↓
WebFormsJS
  ↓
HTML DOM

The browser still performs the actual DOM operations, but the developer does not need to implement those operations as custom JavaScript code.

This is particularly useful for applications where interaction logic is already organized around server-side controls and commands.

No Custom JavaScript Required

The only JavaScript referenced by the page is the WebFormsJS executor:

<script type="module" src="/script/web-forms.js"></script>

There is no custom JavaScript file containing drag-and-drop handlers.

The HTML remains ordinary HTML, and the draggable elements use the standard draggable attribute:

<div class="dragitem" id="dragitem1" draggable="true">
    Drag me! 1
</div>

The interaction logic is defined entirely through the server-side WebForms API.

Conclusion

This example shows that Drag and Drop does not necessarily require a custom JavaScript implementation.

With WebForms Core, mouse-based Drag and Drop can be defined through standard HTML events and server-generated commands, while touch interaction can be handled through a separate OnTouchStart event.

The result is a server-orchestrated interaction where:

the server defines the behavior,
WebForms Core generates the commands,
WebFormsJS executes those commands,
and the browser performs the final DOM operations.

Most importantly, the developer does not have to write a JavaScript Drag and Drop implementation or maintain a separate client-side interaction layer.

If you have any questions, feel free to ask.
If you have any comments, please share them.
We will gladly answer!

No React, No Vue, No Angular: Explore the WebForms Core Demo Website in Action

Elanat Framework — Tue, 06 Oct 2026 22:05:44 +0000

The new WebForms Core Demo is now available:

https://webforms-core.github.io/demo

Explore WebForms Core through interactive examples and see how server-orchestrated UI works in practice.

The demo includes examples of:

Chart using an extension method
Custom DOM events
Value formatting
Server-driven rendering with Render
Interactive applications such as a Memory Tiles game

WebForms Core uses a Commander–Executor architecture. The WebForms class generates commands, and WebFormsJS executes them directly on the HTML DOM. The server is stateless, while routing and UI infrastructure are handled automatically, allowing developers to focus on writing the application logic.

No React. No Vue. No Angular. No JSX.

Just server-generated commands and direct DOM execution.

Try the demo now:
https://webforms-core.github.io/demo

Source code
https://github.com/webforms-core/demo

Have You Used WebForms Core? Share Your Experience

Elanat Framework — Tue, 06 Oct 2026 12:26:55 +0000

WebForms Core is launching on Product Hunt on October 7.

If you have already used WebForms Core, I’d really appreciate you sharing your experience and opinion when the launch goes live (October 7).

What did you like? What could be improved? How did you use it in your projects?

Your feedback as someone who has actually used WebForms Core is especially valuable.

WebForms Core on Product Hunt

WebForms Core 2.2 Released: Render, a New Approach to UI Rendering

Elanat Framework — Sun, 04 Oct 2026 12:59:10 +0000

WebForms Core is a modern, server-orchestrated technology for building interactive HTML user interfaces, introduced by Elanat in 2024. It enables direct and deterministic DOM management from the server, eliminating the need for separate client-side frameworks such as React, Vue, or Angular.

WebForms Core 2.2 has been released.

This release introduces several new capabilities, but one feature deserves special attention: Render.

Render is a high-level UI rendering primitive designed to make repeated server-side rendering of an existing HTML element predictable and manageable. It brings together several mechanisms that are all new in this version—Snapshot, Rollback, and Transient DOM—into a single high-level primitive.

The result is a simpler way to replace, rebuild, and restore parts of an HTML document while keeping the operation under server-side control.

Render

In this new version, Snapshot, Rollback, and Render are all new additions. Render is a high-level method that uses Snapshot and Rollback internally.

In WebForms Core 2.2, Render brings these operations together.

A simple example is:

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");

The rendering process can also be used directly with a template:

var data = new Dictionary<string, string>
{
    { "name", name},
    { "email", email},
    { "phone", phone},
    { "age", age},
    { "city", city},
    { "country", country}
};
string json = JsonSerializer.Serialize(data);

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

The important part is not simply the number of lines saved by Render. The important part is that the lifecycle of the rendered element is handled as one operation.

Internally, Render checks whether a previous version of the selected element already exists. If it does, that version is restored. Otherwise, a Snapshot is created.

The rendering process then enters the Transient DOM, appends the generated WebForms commands, exits the Transient DOM, and appends the new form.

In simplified form:

Existing State
      ↓
Rollback or Snapshot
      ↓
Start Transient DOM
      ↓
Apply New Rendering
      ↓
End Transient DOM
      ↓
New UI State

This is particularly useful when the same element has to be rendered repeatedly with different data or templates.

Render and Transient DOM

Render uses the Transient DOM internally.

This is important when selecting InputPlace values inside the Render operation. The root of the selected InputPlace must be considered relative to the Transient DOM being processed.

Render is therefore not simply a shortcut for a sequence of unrelated commands. It creates a controlled rendering process in which the existing state and the new state can be handled together.

The implementation is:

// 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; Therefore, When Selecting InputPlaces, You Must 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;
}

There is also a configuration-based overload:

public WebForms Render(
    System.Action<WebForms> configure,
    string InputPlace,
    string Key = "",
    bool Permanent = false)
{
    var newForm = new WebForms();
    configure(newForm);

    return Render(newForm, InputPlace, Key, Permanent);
}

This makes Render suitable for both manually constructed WebForms and dynamically configured rendering operations.

Snapshot and Rollback

Render is built on top of the Snapshot and Rollback mechanisms introduced in WebForms Core 2.2.

A Snapshot stores the state of a selected tag so that it can later be restored.

Consider a simple multilingual user template.

The page contains three buttons:

<input id="English" type="button" value="en-user">
<input id="Spanish" type="button" value="es-user">
<input id="Persian" type="button" value="fa-user">

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

The templates are defined using HTML <template> elements:

<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>

The WebForms code creates a Snapshot for each template:

using CodeBehind;

public partial class SnapshotAndRollbackController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        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());
    }
}

When one of the buttons is clicked, the corresponding Snapshot is restored and the user data is inserted into the selected template.

The API itself is intentionally small:

public void Snapshot(
    string InputPlace,
    string Key = "",
    bool Permanent = false)

public void Rollback(
    string InputPlace,
    string Key = "",
    bool Permanent = false)

The Snapshot and Rollback mechanism is sensitive to DOM changes, so assigning a stable ID to the selected element is recommended.

Render uses these mechanisms automatically, so developers do not need to manually coordinate Snapshot and Rollback when using the high-level rendering API.

GetTagHash

WebForms Core 2.2 also introduces Fetch.GetTagHash.

It calculates a hash from the outerHTML of a tag.

form.SetCommentEvent(
    "GetHash",
    HtmlEvent.OnClick,
    "get-hash");

form.StartIndex("get-hash");
form.AddText("Text", "-a");
form.Message(Fetch.GetTagHash("Box"));

The hash is based only on the tag's outerHTML.

This makes it useful for detecting whether the DOM representation of a tag has changed.

Formatting Values with Regex

WebForms Core 2.2 adds:

SetFormatCacheValue
SetFormatSaveValue

These methods apply Regex-based formatting to values stored in Cache or Save.

For example, the following page contains a money value and a time value:

<button id="SetFormat">Click to Set Format</button>

<input type="text" id="Money" value="12345678">
<input type="text" id="Clock" value="15:1:3">

The WebForms code stores each value and applies a regular-expression replacement:

using CodeBehind;

public partial class SetFormatController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "SetFormat",
            HtmlEvent.OnClick,
            "set-format");

        form.StartIndex("set-format");

        form.SaveValue("Money", "money");
        form.SetFormatSaveValue(
            "money",
            "(\\d)(?=(\\d{3})+$)",
            "$$1,");

        form.SetValue("Money", Fetch.Save("money"));

        form.CacheValue("Clock", "clock");
        form.SetFormatCacheValue(
            "clock",
            "(^|:)(\\d)(?=:|$)",
            "$$10$2"); // Two $$ for escape JavaScript interpretation

        form.SetValue("Clock", Fetch.Cache("clock"));

        Write(form.ExportToHtmlComment());
    }
}

The first operation formats:

12345678

as:

12,345,678

The second transforms:

15:1:3

into:

15:01:03

The $$ in the replacement string is important because it escapes the $ for JavaScript interpretation.

This is also useful when formatting must happen as part of a larger WebForms operation, where the formatted value can then be applied back to the corresponding HTML element.

Arithmetic Operations

WebForms Core 2.2 adds arithmetic operations for values stored in Cache and Save.

The supported operations are:

+
-
*
/
%
//
**

The following example provides a button for each operation:

<button id="Addition">+</button>
<button id="Subtraction">-</button>
<button id="Multiplication">*</button>
<button id="Division">/</button>
<button id="Remainder">%</button>
<button id="FloorDivision">//</button>
<button id="Power">**</button>

<input type="text" id="Value1" value="10"> |
<input type="text" id="Value2" value="7">
=
<b id="Result"></b>

The WebForms code is:

using CodeBehind;

public partial class ArithmeticController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "<button>*",
            HtmlEvent.OnClick,
            "result");

        form.StartIndex("result");

        form.SaveValue("Value1", "result");

        form.SetArithmeticSaveValue(
            "result",
            Fetch.GetText("$"),
            Fetch.GetValue("Value2"));

        form.SetText(
            "Result",
            Fetch.Save("result"));

        Write(form.ExportToHtmlComment());
    }
}

The // operation is implemented in WebFormsJS as:

case "//":
    return Math.floor(a / b);

For example, with 10 and 7, / produces the normal division result, while // produces the floored result.

The operations allow common numerical transformations to be performed directly within the WebForms command flow.

Text Operations

WebForms Core 2.2 currently provides six text operations:

textafter
textafterlast
textbefore
textbeforelast
substring
remove

The example below provides a button for each operation:

<button>textafter</button>
<button>textafterlast</button>
<button>textbefore</button>
<button>textbeforelast</button>
<button>substring</button>
<button>remove</button>

<input type="text" id="Value1" value="This is a Hello World!"> |
<input type="text" id="Value2" value=""> |
<input type="text" id="Value3" value="">
=
<b id="Result"></b>

The WebForms implementation is:

using CodeBehind;

public partial class TextOperationController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "<button>*",
            HtmlEvent.OnClick,
            "result");

        form.StartIndex("result");

        form.SaveValue("Value1", "result");

        form.SetTextOperationSaveValue(
            "result",
            Fetch.GetText("$"),
            Fetch.GetValue("Value2"),
            Fetch.GetValue("Value3"));

        form.SetText(
            "Result",
            Fetch.Save("result"));

        Write(form.ExportToHtmlComment());
    }
}

The current set is intentionally compact. More text operations can be added in future versions based on developer feedback and practical use.

Regex-Based Element Selection

The Criteria system can use regular expressions to select elements.

Consider the following HTML:

<div id="Regex">
    <div>2026-10-01</div>
    <div>Adrian</div>
    <div>43</div>
    <div>00125478744</div>
    <div>Brazil</div>
</div>

The following commands select elements based on their text:

form.SetBackgroundColor(
    "Regex|*?t#\\d{4}-\\d{2}-\\d{2}$",
    "pink");

form.SetBackgroundColor(
    "Regex|*?t#^[0-9]+$",
    "brown");

The t criterion works with the text of the element, while # specifies a regular-expression comparison.

The first expression matches a date such as:

2026-10-01

The second matches text consisting entirely of digits, such as:

43
00125478744

The underlying WebFormsJS implementation uses JavaScript's RegExp:

case '#':
{
    let pattern = tmpValue;
    let flags = "";

    const m = pattern.match(/^\/([\s\S]+)\/([a-z]*)$/);

    if (m)
    {
        pattern = m[1];
        flags = m[2];
    }

    try
    {
        result = new RegExp(pattern, flags).test(text);
    }
    catch
    {
        result = false;
    }

    break;
}

This allows the Criteria system to perform more precise element selection without requiring a separate selector language.

JavaScript Objects from WebForms

A value beginning with $ in a WebForms class method can be interpreted by WebFormsJS as a JavaScript object reference.

This provides a direct way for server-generated commands to refer to objects that exist in the browser.

The distinction is important: the WebForms class generates the command, while WebFormsJS performs the corresponding client-side execution.

Try and Catch

WebForms Core 2.2 adds Try and Catch for explicit error handling.

For example:

form.Try();

form.AddTag("<h5>", "div");
form.SetText("<h5>|<>-1", "New tag!");
form.Message("New Tag Was Added!");

form.Catch();

form.Message("h5 Tag Not Exist 1!");
form.Message("h5 Tag Not Exist 2!");

If an Action Control inside Try encounters an error, execution stops and continues at Catch.

Without Try and Catch, there is no automatic recovery mechanism. The developer decides which operations may cause problems and places those operations inside an appropriate error-handling structure.

LockQueue

The queue behavior was changed in WebForms Core 2.2.

In the previous version, the queue was automatically locked. In 2.2, the queue is no longer automatically locked in that way.

The default duration is controlled by:

WebFormsOptions.QueueLockDuration = 100;

When a process needs additional protection, the developer can explicitly call:

form.LockQueue(10000);

LockQueue dynamically increases the lock duration for the current process and then restores the previous configured value automatically.

This is useful when a process must be allowed to complete before another queued process starts doing something else.

Native HTML Validation from the Server

WebForms Core 2.2 adds SetCustomValidity.

WebForms Core does not introduce a new validation framework.

Instead, it brings the browser's existing validation capability into the server-generated command model.

For example:

form.SetCommentEvent(
    "(name)",
    HtmlEvent.OnInput,
    "custom-validity");

form.StartIndex("custom-validity");

form.IsEqualTo("admin", Fetch.GetValue("$"));

form.SetCustomValidity(
    "$",
    "The username cannot be \"admin\".");

form.Else();

form.SetCustomValidity("$", "");

The browser's native Constraint Validation API remains responsible for the validation behavior.

The server determines the condition and sends the appropriate command to the HTML element.

Stable WebAssembly Support

WebForms Core 2.2 brings stable WebAssembly support across seven languages and environments:

AssemblyScript
C
C++
C#
Go
Java
Rust

Go and Rust provide WebAssembly targets directly, while AssemblyScript is designed specifically for WebAssembly.

For example, Go can be built with its native WebAssembly target:

@echo off

set GOOS=js
set GOARCH=wasm

go build -o webforms-go.wasm

for /f "delims=" %%i in ('go env GOROOT') do set GOROOT=%%i

copy "%GOROOT%\lib\wasm\wasm_exec.js" wasm_exec.js

pause

Rust can be built with the WebAssembly target and processed with wasm-bindgen:

cargo +stable-x86_64-pc-windows-gnu build --release --target wasm32-unknown-unknown

wasm-bindgen target/wasm32-unknown-unknown/release/webformscore_wasm_test.wasm --target web --out-dir pkg

The current implementations are:

AssemblyScript: WebAssembly
C: Emscripten
C++: Emscripten
C#: AOT and Runtime
Go: native WebAssembly support
Java: TeaVM
Rust: native WebAssembly support and wasm-bindgen

WebAssembly does not change the WebForms Core command model. It provides another execution environment while WebForms Core continues to generate WebForms responses and commands.

WebForms Classes Across 18 Programming Languages

WebForms Classes are now directly available for 18 programming languages, making WebForms Core accessible across a broad range of programming environments.

The collection includes AssemblyScript, C, C++, C#, Dart, Elixir, Go, Java, JavaScript, Julia, Perl, PHP, Python, R, Ruby, Rust, Swift, and TypeScript.

WebForms Core 2.2 is currently available for .NET and Java. The remaining language implementations will be updated to version 2.2 over the next 10 days.

This means the WebForms Classes ecosystem is not limited to a single backend language. Developers can use the same WebForms Core architecture and programming model across a wide range of languages and environments, while each implementation remains native to its own ecosystem.

Why WebForms Core Did Not Add Middleware

One of the hardest architectural decisions during the development of 2.2 was whether to introduce a generic Middleware structure into WebForms Core.

Technically, it was possible to build a very general Function-level Middleware system.

For example:

function A(x, y) {
    const result = Middleware.call(this, A, B, arguments);

    if (result !== undefined)
        return result;

    return x * y;
}

function B(x, y) {
    return [2, 20];
}

function Middleware(method, middleware, args) {
    if (!(this.__middleware ??= []).includes(method.name)) {
        this.__middleware.push(method.name);

        const newArgs = middleware.apply(this, args);
        const result = method.apply(this, newArgs);

        this.__middleware.splice(
            this.__middleware.indexOf(method.name),
            1);

        return result;
    }
}

Such a system could do much more than a conventional Middleware implementation. It could change arguments, stop execution, and execute the original function again with new arguments.

But there was a problem.

Adding this abstraction to WebFormsJS would make the core considerably more complicated. Lifecycle management, recursion, execution order, argument changes, and the different paths through which Functions are executed would all have to be managed.

In the end, we decided not to add it.

Instead, when a requirement is genuinely specific to client-side processing, a JavaScript Module is a better place for that logic.

For example, if form data needs to be reduced or modified before submission, a JavaScript Module can perform that operation directly without adding a generic Middleware layer to WebFormsJS.

This decision is not a statement that Middleware is impossible in WebForms Core.

It is an architectural decision to keep the core smaller and move client-specific behavior into JavaScript Modules.

Other Changes

WebForms Core 2.2 also includes several smaller improvements and fixes.

Reflection renamed to Reflect

The Reflection method has been renamed to:

Reflect

Debugger numbering

Debugger logs now include numbering, making it easier to follow the execution sequence of generated Action Controls.

JavaScript Object escaping

An escaping issue involving JavaScript Objects containing two consecutive $ characters was fixed.

WebForms Core 2.1.1 and 2.1.2

The 2.1.x maintenance releases also included several changes that lead into the 2.2 release:

Fixed the hash-link behavior so hash links no longer create an unnecessary server request.
Added the Modulo Filter to Criteria.
Fixed Replace behavior for values stored in Save and Cache.
Added Fetch support in InputPlace.
Removed CSharpMediator.
CSharpWASM can infer the JavaScript file path from the WASM file path.
CSharpWASM supports both CLI and AOT.
Rust WASM can be built through wasm-bindgen or directly as WebAssembly.

Final Thoughts

WebForms Core 2.2 is not simply a collection of additional methods.

The most important change is the introduction of higher-level operations that allow developers to describe what should happen to a UI without manually coordinating every underlying step.

Render is the clearest example.

Snapshot, Rollback, and Transient DOM already provided the mechanisms needed to manage complex DOM transformations. Render combines those mechanisms into a single operation that can manage the transition from an existing UI state to a new one.

At the same time, 2.2 keeps the underlying system explicit.

Native browser validation remains native browser validation. Client-specific processing can remain in JavaScript Modules. WebAssembly provides additional execution environments without changing the WebForms Core command model. Queue locking is explicit when a process actually needs it.

The result is a more capable WebForms Core without turning the core itself into a larger collection of abstractions.

DEV Community: Elanat Framework

Return template

Introduction

The Challenge of Dynamic Content

Understanding Return Templates

A Practical Example

Standard Syntax Support

Why This Approach Matters

Conclusion

Related links

Working with templates in View

Introduction

Creating Your First Template

The Same Example in Standard Syntax

Organizing Templates in External Files

Keeping Views Consistent Across an Application

Conclusion

Related links

WebForms Core 2.3 Progress Update: Component Begin, WebForms Core Begin!

Component System

DoComponent

RenderList

GetFormJSON

A New Variable System

Page-Level Race Condition Protection

Replacing the * Magic Character in DeleteAll

SafeValue Now Handles HTML Encoding

UpdateLineByIndex Fix

WebFormsJS Improvements

<main> Becomes the Default Location

Modal

What Is Left?

Related Links

WFC in R Programming Language

WebForms Core in R

Installation

A Digital Clock with WFC

Note on the script/web-forms.js Path

How It Works

No Manual JavaScript

Installing WebFormsJS

Why This Is Interesting for R

Conclusion

Related links

WebForms Core 2.3 Will Be Released in November 2026

Component System & Scope

Example: A Counter Component in Blazor Server

EnableAutoCleanup

Request & Action Control Lifecycle Management

Rendered Value Mirroring

RunWebForms

SetResponse

Hash URL State Management

Transient DOM Improvements

Loader Improvements

SPALink Improvements

Native Form Behavior

Overall Direction

Related Links

CodeBehind Is About 19% Faster Than ASP.NET MVC in the Latest Benchmark

Benchmark Results

An Important Detail About the CodeBehind Execution Model

This Performance Did Not Come From a Single Change

Removing Unnecessary Processing

Performance Through Simplification

CodeBehind and ASP.NET MVC

More Than a Benchmark Number

Conclusion

Related Links

Building a Bubble Popping Game with WebForms Core + Online Demo

1. Defining the Game Interface

Styling the bubbles

2. Initializing WebForms Core

3. Starting a New Game

4. Creating Bubbles Dynamically

5. Moving the Bubble

6. Popping a Bubble and Updating the Score

7. Ending the Game

8. Exporting the Commands

Conclusion

Replacing the `*` Magic Character in DeleteAll

`<main>` Becomes the Default Location

Note on the `script/web-forms.js` Path