Forem: Elanat Framework

Using the Segment Feature

Elanat Framework — Fri, 27 Feb 2026 21:28:20 +0000

Segment is an attribute that can be applied to ASPX pages. When this feature is enabled, all path parts that appear after the aspx file path are treated as segments and routed to the same executing page. Segment is one of the innovative ideas of the Elanat team. By enabling Segment, you gain full control over URL paths.

Enabling Segment

Razor Syntax

@page
+@segment
<!DOCTYPE html>
<html>
...

Standard ASPX Syntax

<%@ Page Segment="true" %>
<!DOCTYPE html>
<html>
...

How Segment Works

If you enable Segment on the following path:

/page/about.aspx

Any additional path parts after this address will be considered segments, and the executable file /page/about.aspx will still be executed.

Example

/page/about.aspx/segment1/segment2/.../segmentN

If Segment is enabled on a file such as:

/page/about/Default.aspx

You can still access it using both of the following formats:

/page/about/Default.aspx/segment1/segment2/.../segmentN

/page/about/segment1/segment2/.../segmentN

Accessing Segment Values

You can access Segment values in all three layers: View, Controller, and Model.

Segments are zero-based indexed.

Given the URL:

/page/about/segment1/segment2/segment3

Segment.GetValue(0) returns "segment1"
Segment.GetValue(1) returns "segment2"
Segment.GetValue(2) returns "segment3"

In general:

Segment.GetValue(n)

returns the segment at index n (starting from 0).

Example in View (Razor)

<b>segment 1 is: @Segment.GetValue(0)</b>
<b>segment 2 is: @Segment.GetValue(1)</b>

Example in View (Standard ASPX)

<b>segment 1 is: <%= Segment.GetValue(0) %></b>
<b>segment 2 is: <%= Segment.GetValue(1) %></b>

Example in Controller

using CodeBehind;

namespace YourProjectName
{
    public partial class DefaultController : CodeBehindController
    {
        public void PageLoad(HttpContext context)
        {
+           Write(Segment.GetValue(0));
+           Write(Segment.GetValue(1));
        }
    }
}

By activating Segment, you no longer need to use query strings to pass parameters through the URL.

Important Behavior

If you enable Segment on a specific path, ASPX view files located in its subdirectories will not be executed.

Example

If Segment is enabled on:

/page/about/Default.aspx

Then the following path will no longer be accessible:

/page/about/license/Default.aspx

Checking Segment Existence

You can use the Exist method to check whether a segment value exists before accessing it.

@if (!Segment.Exist(0))
{
    <b>Value does not exist</b>
}

Segment in Default MVC Configuration

In the default MVC configuration, the Segment feature is enabled automatically in controller routing.

using CodeBehind;

public partial class user : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {   
        Write(Segment.GetValue(0)); // path: /user/{id}
    }
}

Rewrite ASPX Path as Directory

One of the interesting ideas introduced by the Elanat team in the CodeBehind framework is the ability to rewrite an aspx file path as a directory name.

When this option is enabled, routes leading to an aspx file without the .aspx extension will be treated as directory paths.

[CodeBehind options]; do not change order
...
rewrite_aspx_file_to_directory=true
...

Note: You can safely enable this option because this rewrite does not introduce any additional processing load.

Example

Access:

/page/contact.aspx

Using:

/page/contact

And also:

/page/contact/segment1/segment2/.../segmentN

🎬 Video - Using WebForms Core in ASP.NET MVC

Elanat Framework — Fri, 27 Feb 2026 12:47:45 +0000

In this video, we will teach you how to configure and use Elanat's WebForms Core technology in ASP.NET MVC.

Is Blazor a Replacement for WebForms?

Microsoft officially presents it as such, but the technical reality is more nuanced:

Blazor = Component-Based Framework
WebForms = Event-Driven Page Model

These two are built on fundamentally different architectural philosophies.

📌 Blazor is not a technical replacement for WebForms; it is a strategic replacement.

Blazor is designed around a component-based architecture, whereas WebForms was built on a page-centric, event-driven model. Therefore, they cannot be considered equivalent.

The WebForms Core Perspective on Modern Architecture

WebForms Core does not “destroy” the separation between front-end and back-end;
it abstracts it.

Instead of forcing developers to build and maintain two separate projects using two different languages, this architecture turns the front-end into an execution layer that is controlled entirely from the server-side language.

In this approach, user interactions remain modern, dynamic, and refresh-free, while the complexity of managing front-end code is removed or hidden from the developer.

From AJAX to WebForms Core

Technologies like AJAX in 2005 created a major shift in web development by enabling data exchange without requiring a full page refresh.

WebForms Core can be seen as the most evolved continuation of that path — a transition from:

“Interaction without page refresh”

“Interaction without direct front-end coding.”

This is not merely a tooling change;
it represents a shift in development philosophy.

ViewData in CodeBehind: Data Transfer Across MVC Components

Elanat Framework — Fri, 27 Feb 2026 09:33:28 +0000

The ViewData feature in the CodeBehind framework, developed by Elanat, is a simple and practical mechanism for transferring data between different components of the MVC architecture.

What is ViewData?

ViewData is a data list of type NameValue (Key-Value).
This structure allows you to store data with a specific key and retrieve it in other parts of the same request.

ViewData is used to transfer data between MVC components and supports both reading and writing in the following sections:

Controller
Model
View
Layout

ViewData Lifetime

An important point to consider is that the data stored in ViewData is valid only during the current HTTP request.

This means that once the request is completed and the response is sent to the client, the ViewData values are cleared and will not be available in subsequent requests.

Comparison with ASP.NET

The overall behavior of ViewData in CodeBehind is very similar to ViewData in:

ASP.NET MVC
ASP.NET Razor Pages

If you have previously worked with these technologies, using ViewData in CodeBehind will feel familiar and intuitive.

Writing Priority in ViewData

The writing priority order in ViewData is as follows:

Controller
Model
View

This reflects the execution flow of the MVC pattern.

If a new ViewData value is created inside the View, it cannot be read in the Controller, because the Controller executes before the View.

Example: Using ViewData in a View

In the following example, the title value is set inside the View:

@page
@controller CacheThemeController
@layout "/layout.aspx"
@{
  ViewData.Add("title","Cache Theme");
}

Here, the value "Cache Theme" is stored with the key "title".

Accessing ViewData in a Layout

The stored value can be retrieved inside the Layout file:

@page
@islayout
@{
    string WelcomeText = "Welcome to the CodeBehind Framework!";
}
<!DOCTYPE html>
<html>
<head>
    <title>CodeBehind Framework - @ViewData.GetValue("title")</title>

In this example, the title value defined in the View is accessed in the Layout and displayed inside the <title> tag.

Using ViewData in a Controller

You can also assign values inside a Controller:

public void PageLoad(HttpContext context)
{   
    ViewData.Add("name", "Adriano");
}

In this case, the value "Adriano" is stored in ViewData and becomes accessible in the View.

Reading ViewData in a View

@page
@controller ChangeListController

Name: @ViewData.GetValue("name")

Here, the value associated with the specified key is retrieved from ViewData and rendered in the View.

Advantages of ViewData

Using ViewData in CodeBehind offers several advantages:

Simple Key-Value structure for lightweight data transfer
No need to create additional models for small or temporary data
Accessible across Controller, Model, View, and Layout
Request-scoped lifetime, ensuring clean and predictable data handling
Lightweight and fast, with minimal overhead
Familiar pattern for developers coming from ASP.NET MVC or Razor Pages

Conclusion

ViewData in CodeBehind is a lightweight, flexible, and efficient mechanism for transferring data between MVC components within a single request.

It is especially suitable for passing small pieces of data such as page titles, UI settings, temporary messages, or configuration values—without introducing unnecessary complexity into your application architecture.

Why You Can’t Write to the Response in ASP.NET Core (And How to Fix It)

Elanat Framework — Tue, 24 Feb 2026 16:41:15 +0000

In ASP.NET Core, once a View starts rendering, your ability to modify the response is essentially gone. Try writing to Response.Body — and you’ll quickly hit a wall.

If you’ve ever tried writing to Response.Body after a Razor View or MVC Controller started rendering, you know the pain: System.InvalidOperationException: Response already started!

This is not just an exception problem — it’s a response pipeline limitation.

We at Elanat recently released a lightweight middleware called ResponseWrite that solves this problem in a clean and modular way.

The Problem

In ASP.NET Core, once headers are sent or the View starts rendering, writing directly to the response stream usually triggers errors. Microsoft's usual workaround—ViewData, ViewBag, Partial Views, or View Components—is not dynamic, tightly couples modules to Views, and isn’t usable from middleware.

Microsoft’s Recommended Approach (Not a Real Solution)

Instead of writing directly to the response stream, the typical recommendation is to pass data from the PageModel (or Controller) to the View using ViewData (or ViewBag).

PageModel

public class IndexModel : PageModel
{
    public IActionResult OnGet()
    {
        ViewData["FooterMessage"] = "Hello from Elanat!";
        return Page();
    }
}

View (`Index.cshtml`)

@page
@model IndexModel
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Microsoft Recommended Pattern</title>
</head>
<body>
    <h1>Welcome</h1>
    <p>This is content from the View.</p>

    @ViewData["FooterMessage"]
</body>
</html>

Why This Doesn’t Truly Solve the Problem

This works — but only because the View was explicitly modified to render @ViewData["FooterMessage"].

That means:

The injection point must already exist.
The View must know the exact key name.
Middleware cannot safely use this pattern.
Modules are tightly coupled to specific Views.

This is a View-level data passing technique — not a response pipeline solution.

The Solution

ResponseWrite queues content during request execution and appends it to the response just before it’s closed. You can use it anywhere: Razor Pages, MVC Controllers, or even other middleware.

Example

Razor Page (`.cshtml`)

Assuming your Razor Page is Index.cshtml:

@page
@model IndexModel
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>ResponseWrite Demo</title>
</head>
<body>
    <h1>Welcome to ResponseWrite Demo</h1>
    <p>This is content from the View.</p>
</body>
</html>

Page Model (`Index.cshtml.cs`)

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

public class IndexModel : PageModel
{
    public IActionResult OnGet()
    {
        Response.Write("Hello from Elanat!"); // Safe anytime
        return Page();
    }
}

When Response.Write is called:

The content is queued during request execution.
The View is rendered normally.
Just before the response is finalized, ResponseWrite appends the queued content to the output.

Register Middleware

In your "Program.cs":

app.UseResponseWrite(); // Add this before app.Run()

Final HTML Output

With ResponseWrite, the final HTML received by the browser will look like this:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>ResponseWrite Demo</title>
</head>
<body>
    <h1>Welcome to ResponseWrite Demo</h1>
    <p>This is content from the View.</p>
</body>
</html>
Hello from Elanat!

Note: The "Hello from Elanat!" text appears after the View HTML because ResponseWrite appends the content at the end of the response before it is sent to the client.

Features

Prevents response stream write timing issues
Works across Razor Pages, MVC, and Minimal APIs
Middleware-level solution (not View-level workaround)
Zero dependencies
Modular and plugin-friendly

WebForms Core Example

This middleware is fully compatible with WebForms Core, a technology developed by Elanat.

public IActionResult OnGet()
{
    WebForms form = new WebForms();
    form.SetBackgroundColor("<body>", "violet");

    Response.Write(form.ExportToHtmlComment());
    return Page();
}

Installation

dotnet add package ResponseWrite

NuGet Package →
GitHub Source →

If you’re building modular systems, CMS platforms, or plugin-based architectures in ASP.NET Core, ResponseWrite might save you from fighting the response pipeline.

If this solves a pain point for you, feel free to try it, open an issue, or contribute on GitHub.
Feedback and architectural discussions are always welcome.

Loading a View Inside Another View in CodeBehind (SSR vs CSR)

Elanat Framework — Mon, 23 Feb 2026 12:49:06 +0000

In this tutorial, you will learn two different approaches to compose modular web pages using the CodeBehind framework: Server-Side Rendering (SSR) with LoadPage, and Client-Side Rendering (CSR) with WebForms Core."

Server-Side Rendering (SSR) means the server fully generates the HTML before sending it to the browser.

Client-Side Rendering (CSR) means part of the page is loaded or generated after the main page has already been delivered to the browser.

In modern web development, it is often necessary to divide a web page into independent and modular parts so that each part can be managed according to the type of data, level of dynamism and need for customization.

There are multiple ways to load one page inside another. However, not all approaches are optimal in terms of performance and scalability. In this article, we focus only on two recommended strategies. Here we will teach you two approaches, one of which is based on SSR and the other is CSR.

Let's start with the server-side approach.

Load Page Example

In this example, we create a simple user profile module that will later be injected into another page.

Creating the Module

Module ("/module/user_profile.aspx")

@page
<div style="position: fixed; top: 10px; right: 10px; display: flex; align-items: center; gap: 10px;">
    <span>🔔</span>
    <img src="https://ui-avatars.com/api/?name=adriano" style="width: 40px; height: 40px; border-radius: 50%;">
    <span>Adriano Armisen</span>
    <span>▼</span>
</div>

Server-Side Rendering (SSR) with LoadPage

In this case, in the View page, using the LoadPage method, we can add the desired page to the desired section of the HTML page.

Using LoadPage in the View

@page
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>CodeBehind Framework Call Page SSR Mode</title>
</head>
<body>

  @LoadPage("/module/user_profile.aspx")

  <h1>CodeBehind Framework</h1>
  <p>CodeBehind Framework is a lightweight ASP.NET-based web framework that simplifies development by separating HTML structure from server-side logic without relying on MVC or Razor.</p>

</body>
</html>

How LoadPage Works?

When using LoadPage, the server executes the requested page and injects its rendered HTML into the current page before sending the final output to the client.

When You Should Avoid SSR

However, SSR is not always the best solution. In some scenarios, a different approach is more efficient.

Consider a page where some users are logged in and some are using its features without registering. On many websites, a logged-in user sees a menu at the top of the page that is specific to their account, while the rest of the site is the same for all users.

One bad decision in this scenario is to render this user-specific menu as SSR and send it to the user along with the entire HTML of the page. In this case, the server is forced to generate a different version of the HTML for each user. The result of this is:

Prevents full-page CDN caching
Reduced effectiveness of server-side and client-side caching
Increased processing pressure on the server
Loss of scalability at high traffic

Therefore, using SSR for user-specific content can negatively impact performance and caching strategy in high-traffic applications.

While the main body of the page can be fully cacheable and shared by all users, only the login-specific part needs to be loaded separately.

This is where AJAX comes into play;
Instead of generating a completely customized HTML, you can send the main page as a public, cacheable page, and then retrieve and replace the user-dependent parts separately and dynamically.

Of course, using AJAX increases the complexity of the architecture and state management on the client side to some extent. You have to define separate endpoints, manage login status, handle errors, and in some cases encounter problems such as UI synchronization or loading state.

But fortunately, in the CodeBehind framework, you can use WebForms Core technology to add different parts of the page in a modular and independent way after loading the main page, without the need to directly implement AJAX.

Client-Side Rendering (CSR) with WebForms Core

WebForms Core is a client-side execution layer in the CodeBehind framework that allows dynamic content injection after the initial page load.

In this approach:

First, the main body of the page is sent as a public, cacheable page.
Then, the controls or components dependent on the user's state are processed separately and added to the output after the initial execution of the page.
This process is done without the need to write manual AJAX code.
At the same time, the page structure remains discrete and scalable.

Example

@page
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>CodeBehind Framework Call Page CSR Mode</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
@{
  WebForms form = new WebForms();
  form.AddTextToUp("<body>", Fetch.LoadUrl("/module/user_profile.aspx"));
}

@form.ExportToHtmlComment()

  <h1>CodeBehind Framework</h1>
  <p>CodeBehind Framework is a lightweight ASP.NET-based web framework that simplifies development by separating HTML structure from server-side logic without relying on MVC or Razor.</p>

</body>
</html>

Fetch.LoadUrl is not executed on the server. Instead, it generates instructions that tell the client to asynchronously retrieve the module page after the main page loads
AddTextToUp injects the loaded content to the top of the <body> element.
ExportToHtmlComment renders the required instructions for WebForms Core to process the dynamic content on the client side.

It is recommended to implement client caching in CSR mode for the module page so that it is requested from the server only once.

The output of both methods is the same for the end user, but CSR mode makes one more request to the server.

CSR helps maintain full-page CDN caching while isolating user-specific components into independent requests.

Final Result

The following screenshot shows the final rendered HTML in the browser for both approaches.

Comparison of CSR and SSR

The following table summarizes the differences between SSR and CSR in CodeBehind:

Feature	SSR	CSR
Rendering Location	Server	Client
Extra HTTP Request	No	Yes
CDN Friendly	Limited for user-based content	High
Complexity	Low	Medium
Best Use Case	Shared content	User-specific modules

Note: This is only a demonstration of page composition. In real applications, always validate authentication and authorization on the server side, even when using CSR.

@page
@if (IsUser)
{
<div style="position: fixed; top: 10px; right: 10px; display: flex; align-items: center; gap: 10px;">
    <span>🔔</span>
    <img src="https://ui-avatars.com/api/?name=adriano" style="width: 40px; height: 40px; border-radius: 50%;">
    <span>Adriano Armisen</span>
    <span>▼</span>
</div>
}

Conclusion

In this article, we explored two approaches for composing modular pages in the CodeBehind framework. SSR using LoadPage is simple and efficient for static or shared content, while CSR using WebForms Core is more suitable for user-specific and dynamic components that should not affect page caching. Choosing the right strategy depends on performance requirements, scalability, and architecture design.

Performance Comparison: React vs WebForms Core

Elanat Framework — Sat, 21 Feb 2026 22:11:34 +0000

Focus on Network Requests, Bandwidth Consumption, and Client Execution Model

In modern web architectures, performance is not only about rendering speed. A critical factor is the communication pattern with the server and the volume of transferred data.

This article compares React and WebForms Core (WFC) strictly from a performance and network perspective, focusing on:

Initial request count
Secondary request count
Initial download size
Bandwidth consumption during interactions
Client execution model
React’s need for build and JSX
HTML structure handling in WFC

This is not a general pros/cons comparison — it is a technical, architectural performance analysis.

1️⃣ Initial Load Phase

React

In a typical React application, the following occurs:

Download of JavaScript bundle (often hundreds of KB to multiple MBs)
Download of React runtime
Execution of hydration or mounting
DOM generation through JavaScript

Even in optimized projects:

One initial HTML request
Multiple JS requests
CSS and other assets

As a result:

📦 Initial payload is usually larger
🌐 Higher number of initial requests
⚙ Initial rendering depends on JavaScript execution

WebForms Core

In WFC:

A standard HTML page is sent from the server
Optionally, a lightweight WebFormsJS file
No heavy bundle
No mandatory build pipeline

In the simplest case:

One HTML request
One small JS request

Result:

📦 Smaller initial payload
🌐 Fewer initial requests
⚙ Page contains usable HTML even before JS executes

2️⃣ User Interactions

This is where architectural differences become more significant.

Scenario A: Pure Client-Side Interaction

WFC Example (KeyUp without server call)

Server code:

public void PageLoad(HttpContext context)
{       
    WebForms form = new WebForms();

    form.SetCommentEvent("TextBox1", HtmlEvent.OnKeyUp, "keyup");
    form.StartIndex("keyup");
    form.SetBackgroundColor("TextBox1", Fetch.GetValue("TextBox1"));

    Write(form.ExportToHtmlComment());
}

Server output:

<!--[web-forms]
EbTextBox1=onkeyup|keyup|
#=keyup
bcTextBox1=@$vTextBox1-->
<input id="TextBox1" type="text" />

In this case:

No request is sent to the server
WebFormsJS parses the comment
The event is registered in the client
DOM is updated directly

Execution model:

Event → Direct DOM manipulation

Requests: 0
Secondary bandwidth: 0

React Equivalent

function App() {
  const [color, setColor] = useState("");

  return (
    <input
      onChange={(e) => setColor(e.target.value)}
      style={{ backgroundColor: color }}
    />
  );
}

Execution model:

Event → setState → Virtual DOM diff → Patch DOM

Requests: 0
Secondary bandwidth: 0

However, internally React:

Maintains state
Executes Virtual DOM diffing
Triggers re-render cycles

WFC in this scenario:

Automatic state with server state engine
No diff algorithm
Direct DOM update

From a CPU perspective in simple cases, WFC introduces less abstraction overhead.

Scenario B: Interaction with Server

React

A typical form submission in React:

fetch("/api/contact", { method: "POST", body: data })

Standard SPA pattern:

AJAX request
JSON response
State update
Re-render

In larger apps:

Multiple API endpoints
Parallel requests
Polling or WebSocket connections

React applications are generally API-driven, meaning frequent server communication.

WebForms Core

WFC preserves the traditional form model:

POST → server → INI response → DOM patch

The key distinction:

The server does not return full HTML.
It returns compact command instructions:

[web-forms]
sd(button)=1
nt<form>=h3
bc<h3>=green
st<h3>=Message

In this case:

Only change instructions are sent
No full HTML re-render
No large JSON state tree

Bandwidth consumption is lower than full page reloads, and typically lighter than API-heavy SPA responses.

3️⃣ Request Patterns in Real Applications

React (SPA Model)

Common behavior:

Large bundle downloaded once
Then dozens or hundreds of API calls
Fully dependent on backend APIs

Benefit: No full page reload
Cost: Continuous API dependency

WebForms Core

Two possible patterns:

Pure client-side interaction (no server calls)
Lightweight roundtrip form-based interaction

In many simple UI cases:

No server request is required

In data-driven cases:

Fewer calls than API-heavy SPAs
Interaction is often form-based rather than endpoint-driven

4️⃣ Bandwidth Consumption

Aspect	React	WebForms Core
Initial download	Large (bundle)	Small
Client-only interaction	0	0
Server interaction	JSON + state updates	Compact instruction commands
API dependency	High	Optional

5️⃣ JSX and Build Requirement

React

React is rarely used without a build process.

Why?

JSX must be transpiled
Modules must be bundled
Optimizations must be applied

In React:

HTML is written inside JavaScript
UI structure depends on runtime
Without JS, nothing renders

WebForms Core

HTML remains standard
No JSX
No mandatory build step
View is independent and inspectable

Server logic remains separate from HTML markup.

6️⃣ Development Model Perspective

React:

UI = function(state)
State-driven
Re-render-driven
Data-centric architecture

WebForms Core:

UI = HTML
Behavior = commands
Event-driven
Command-based execution

7️⃣ Final Technical Summary

If the evaluation focuses strictly on network and bandwidth:

React

Larger initial payload
API-heavy interaction model
Client-side state engine

WebForms Core

Smaller initial payload
Ability to operate without server calls
Compact instruction-based server responses
No diff engine required

Summary of Network & Structural Behavior

Conclusion

React represents a full SPA architecture with a client-side state engine, requiring bundling, build pipelines, and extensive API usage.

WebForms Core represents a hybrid model that can:

Operate fully client-side
Or communicate with minimal bandwidth using compact command instructions
Avoid complex client state engines
Eliminate mandatory build pipelines

From a network and bandwidth perspective:

WebForms Core tends to be lighter in traditional, form-centric applications.
React provides stronger data-flow control in large, API-driven applications.

Modular Structure in CodeBehind

Elanat Framework — Fri, 20 Feb 2026 23:30:28 +0000

What is CodeBehind?

CodeBehind is a powerful backend framework built upon years of experience and research on ASP.NET WebForms from Microsoft. This framework, developed by Elanat, is designed for the latest .NET versions (currently .NET 10).

CodeBehind’s Modular Structure

By default, CodeBehind provides a revolutionary modular structure. In this structure, you can copy and paste an ASPX file along with its compiled DLL from another project into a live web system without needing to rebuild or republish the entire project.

This capability gives developers a vanilla PHP–like experience in a compiled .NET environment: lightweight, flexible, and fast. Essentially, any project built with CodeBehind is inherently modular.

How to Create a New Module

As mentioned, you can copy either an ASPX file or a DLL. Here’s how to handle these two scenarios separately.

Example 1: View Only

In WebForms Core, you can have a View without a controller. This means a single ASPX file can itself be a module.

Here’s a simple ASPX view that generates random numbers:

random.aspx

@page
@layout "/layout.aspx"
@{
    // Generate a random number between 1 and 100
    var rnd = new Random();
    int number = rnd.Next(1, 101);

    // Generate a message based on the number
    string message = number > 50 ? "The number is big!" : "The number is small!";
}

<h2>Random Number Generator in CodeBehind</h2>
<p>Your random number: <strong>@number</strong></p>
<p>Message: <em>@message</em></p>

<ul>
@for (int i = 0; i < 5; i++)
{
    <li>Another random number: @rnd.Next(1, 101)</li>
}
</ul>

<p style="color: green;">Here is a list of 5 more random numbers.</p>

Place the View file anywhere in the wwwroot directory (this path is configurable).

⚠️ Note: To add a module (in this case, a View), you need a mechanism to trigger the compilation step:

SetCodeBehind.CodeBehindCompiler.ReCompile();

You can, for example, create a View management page where you upload new Views and then call the code above after a successful upload.

Example 2: DLL Module

Steps to create a module project:

Step 1: Create a new empty ASP.NET Core project in Visual Studio Code (targeting .NET 10.0).

Step 2: Install the latest CodeBehind framework via NuGet packages.

Step 3: Configure the Program.cs class:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.Run();

Step 4: Create a Default.aspx file under wwwroot/about:

@page
@layout "/layout.aspx"
@controller ModuleProject.AboutController
<p>
    An "About Us" page provides information about a company, organization, or individual. 
    It tells the brand’s story, shares its vision, history, and values, introduces the team, 
    and builds trust with users.
</p>

Step 5: Add a controller class:

using CodeBehind;

namespace ModuleProject
{
    public partial class AboutController : CodeBehindController
    {
        public void PageLoad(HttpContext context)
        {
            ViewData.Add("title", "About page");
        }
    }
}

Step 6: Publish the project.

Now, to deploy the module:

Copy the Default.aspx file to wwwroot/about in the live project.
Copy the compiled DLL from the module project into wwwroot/bin.
Trigger the compilation mechanism:

SetCodeBehind.CodeBehindCompiler.ReCompile();

After this, your new module is fully active and integrated into the live system without rebuilding the main project.

This structure demonstrates the true modularity of CodeBehind: independent Views and DLLs can be added dynamically, making development fast, flexible, and very close to a “vanilla PHP” experience in a fully compiled .NET environment.

Everything Automated: No Client Routing, No Manual Mapping, No Frontend State Management, No Build Pipeline, No Separate UI API

Elanat Framework — Wed, 18 Feb 2026 20:59:45 +0000

WebForms Core, introduced to the web world in 2024 by the Elanat development team, is a structured response to the growing crisis of frontend complexity and JavaScript fatigue that has challenged the developer community in recent years. WebForms Core is a server-command–driven UI automation framework that minimizes client-side logic while preserving dynamic interactivity.

While mainstream web development paradigms have shifted toward moving all processing, state management, and rendering responsibilities to the browser, WebForms Core introduces a strategic shift through the Commander–Executor model, where:

The server acts as the centralized decision-making core.
The client is responsible only for executing commands.

The fundamental objective of this technology is to eliminate the need for manual frontend coding, automate data serialization, intelligently manage events, and ultimately simplify development to the point where mastery of server-side languages alone enables the creation of highly dynamic and complex user interfaces.

Philosophical Foundations and the Necessity of WebForms Core in the Modern Ecosystem

The evolution of the web from static pages to Single Page Applications (SPAs) led to the emergence of heavyweight frameworks such as:

React
Angular
Vue.js

However, this evolution came at significant cost:

Increased JavaScript bundle sizes
Complex state management (Redux, Vuex, Context API)
SEO challenges
Separation of frontend and backend teams
Growing developer burnout from constant context switching

WebForms Core proposes a model in which automation is not a feature — it is the backbone of the system.

In this architecture:

WebFormsJS acts as a lightweight interpreter in the client.
It automatically converts server-issued commands into DOM changes.
No manual DOM diffing, mapping, or JavaScript orchestration is required.

Conceptually inspired by Microsoft ASP.NET Web Forms, WebForms Core eliminates its historical weaknesses such as:

Heavy ViewState
Platform dependency
Lack of HTML control

WebForms Core is a bidirectional protocol where:

Heavy execution occurs client-side via WebFormsJS.
Control logic is issued as Action Control commands from the server.

Developers are freed from:

Manual AJAX implementation
DOM event wiring
Server-client synchronization management
Building and maintaining separate REST/GraphQL APIs for UI interactions

Architectural Comparison

Parameter	Modern SPA Frameworks	WebForms Core
Decision Authority	Client (JS logic)	Server (central business logic)
Core Library Size	200–500 KB	40–110 KB (WebFormsJS)
State Management	Manual (Redux, Vuex, Context API)	Automatic (Stateless relative to DOM)
UI Update Mechanism	Virtual DOM diffing	Direct Action Control execution
Data Serialization	Manual (JSON.stringify / Fetch API)	Automatic based on form type and content
SEO	Requires SSR / prerendering	Natively SEO-friendly (HTML-first)
Development Complexity	High (multiple layers)	Very Low (server-centric development)

Action Controls Architecture: The Automated Language of Server–Client Interaction

The heart of automation in WebForms Core is the Action Controls protocol, designed in a lightweight INI-based format to minimize bandwidth consumption.

Instead of returning:

Entire HTML pages
Or large JSON payloads that require client-side interpretation and mapping

The server sends compact command blocks under the [web-forms] header.

Each line represents a direct operational instruction automatically executed by WebFormsJS.

An Action Control consists of:

Operational code (first two characters)
Tag definition (target identification)
Target value

Examples:

st → Set Text
bc → Background Color

The protocol is transport-agnostic (HTTP, WebSocket, SSE)

Automatic Tag Identification System

WebForms Core eliminates the need for querySelector or JavaScript DOM lookups through a flexible text-based pattern system.

Elements can be targeted via:

ID – Simply by mentioning the ID name
Name – Using parentheses like (name). If a number follows, the corresponding index is selected
Tag Name – Using angle brackets like <tag>. This also supports indexing
Class Name – Using curly braces like {class}
CSS Query – Using the asterisk * followed by a query string
Reference targeting (-) – The dash character refers to the last identified tag, dramatically reducing server response size

Server-side examples:

form.SetText("myId", "Hello");
form.SetBackgroundColor("<form>", "red");

No frontend code required. All UI changes are managed through simple server-side method calls.

Automated Request–Response Lifecycle

In traditional frameworks, developers must:

Listen for submit
Call preventDefault
Manually collect data
Use fetch with proper error handling
Manage loading states
Handle responses and update UI accordingly

In WebForms Core, this chain is fully automated:

Simply adding web-forms.js to the page header automatically:
- Injects PostBack logic into submit inputs
- Injects GetBack logic into <a target="_self"> tags
- Handles all data collection and submission

Lifecycle Stage	WebForms Core Automatic Action	Developer Role
Event Identification	Automatic PostBack/GetBack injection into submit buttons and `<a>` tags	Standard HTML design
Data Collection	Automatic serialization; Multipart detection for file uploads	Define Input tags with proper Name attributes
Request Differentiation	Automatic addition of `Post-Back: true` header for server-side identification	Check for Post-Back header
Response Processing	Automatic interpretation of Action Controls and DOM updates	Call WebForms class methods on the server
Navigation Management	Uses Service Worker and routeAlias for partial page updates	Build pages and manage routes on the server

Intelligent Serialization & Smart Form Submissions (v2.0)

WebForms Core automatically handles data serialization based on content type:

Automatically detects multipart forms (file uploads → FormData)
Encodes standard forms as URL-encoded strings automatically
Adds a custom Post-Back: true header to all interactive requests

In version 2.0, this automation reaches a new level with Smart Form Submissions:

The client monitors changes using checksums (Checksums)
Only fields that have actually been modified are sent to the server
Unchanged fields are excluded from the request

Benefits:

Dramatically reduced bandwidth consumption
Reduced server validation load for unchanged data
Significantly improved performance, especially in forms with many fields

Practical Comparative Examples

Example 1: Rendering 196 Countries in a Dropdown

In React:

Create a backend API endpoint returning JSON data
Write JavaScript to fetch data with useEffect
Manage loading, error, and success states
Iterate through the data with .map()
Manually construct <option> elements
Render to DOM

In WebForms Core:

Server-side loop:

foreach (var country in countryList)
{
    form.AddOptionTag("country", country.Id, country.Name);
}

Server automatically generates compact Action Control commands:

[web-forms]
aocountry=1|USA
aocountry=2|Italy
aocountry=3|France
...

WebFormsJS on the client automatically receives these commands and inserts the elements into the appropriate tag.

Result: No client-side loop, no fetch calls, no state management, and complete elimination of frontend "code clutter." A backend developer can manage complex UIs without frontend expertise.

Example 2: Dynamic Style and Element State Changes

Consider a scenario where, after a button click, you need to:

Change the form's background color
Display a success message to the user
Disable the button
Automatically remove the message after 3 seconds

In WebForms Core, this is accomplished with a few lines of server-side code:

WebForms form = new WebForms();
form.SetBackgroundColor("<form>", "green");
form.AddTag("<form>", "h3");
form.SetText("<h3>", name + "! Your message was successfully sent.");
form.SetDisabled("(button)", true);
form.Delete("<h3>");
form.AssignDelay(3);
Write(form.Response());

WebForms Core automatically packages these commands into INI format (bc<form>=green, st<h3>=..., sd(button)=1) and executes them on the client. The AssignDelay method automatically creates a timing delay for the previous command (deleting the message) without requiring setTimeout in JavaScript.

Stateless Commander–Executor Architecture

Unlike server-side models such as Blazor Server, which maintain a server memory circuit of the client DOM, WebForms Core:

Stores no client DOM snapshot in server memory
Performs no diff calculations
Maintains no per-user UI state

It follows a precise model: Stateless relative to the DOM

Conceptual Distinction

In this architecture:

UI State remains in the browser – All visual states like input values, menu open/closed status, elements added to DOM, and applied style changes stay on the client.
The server holds no copy of the client's DOM – Unlike architectures that maintain a "Shadow DOM" or "Circuit" for interactive server-side rendering.
Each request is processed independently – The server has no knowledge of the client's current state and doesn't need it.
The server only issues commands – Rather than sending data that the client must interpret, the server directly says: "Make tag X green."

This imperative command flow means:

Server memory consumption is independent of the number of online users
No need for server-side diff calculations between DOM versions
Each response contains only new execution commands
Near-zero latency and massive scalability

Result: Minimal client-side processing latency, massive scalability, and memory usage completely independent of concurrent user count.

Transient DOM Concept

WebForms Core introduces Transient DOM, an intelligent evolution of the Virtual DOM concept:

Multiple server-side DOM changes are batched together
Sent to the client in a single transaction
Applied all at once to the real DOM by WebFormsJS

Instead of communicating with the client after each change or forcing the client to re-render at every step, WebForms Core packages all modifications into a unified transaction.

Benefits:

No visual flicker during updates
Dramatically faster UI response time
Significantly reduced client workload
Elimination of intermediate rendering layers

Automation in Advanced Event Management and Synchronization

In traditional web development, going beyond standard HTML events (like click) requires writing custom JavaScript libraries. WebForms Core 2.0 eliminates this limitation by allowing developers to define new DOM events on the server side. These events are seamlessly attached to client elements and are recognized as first-class browser events.

Additionally, the TriggerEvent method allows the server to automatically execute any event on the client. For example, after completing a heavy server-side process, the server can automatically trigger the submit event of another form or the click event of a hidden button in the user's browser.

This transforms the server from a mere responder into an active orchestrator of the user interface.

Automatic External Data Fetching (Fetch Helper Class v2.0)

Version 2.0 introduces a revolutionary Fetch helper class that completely automates data extraction from external sources. This feature allows developers to command the client to retrieve data from an external API and display it in the UI without writing a single line of JavaScript.

Automatic Data Extraction Methods

WebForms Core supports various data formats, each suited to specific scenarios:

Data Type	Method	Typical Use Case	Automation Advantage
JSON	`LoadJSON(url, path)`	REST/GraphQL APIs	Supports XPath-like pathing for nested nodes (e.g., `user.profile.name`); eliminates client-side Async/Await
XML	`LoadXML(url, xpath)`	RSS feeds, sitemaps, structured reports	Precise element extraction using full XPath standard
INI	`LoadINI(url, key)`	Language files, module settings	Implement multi-language systems with a few lines of server code; no heavy i18n libraries needed
Plain Text	`LoadLine(url, line)`	Log files, line-based reports	Direct access to specific text lines without parsing entire files

Process:

The server issues the command
The client performs the "fetch" and "processing" locally
The server is not burdened with the bandwidth of receiving data from third-party APIs
The server only orchestrates the operation

This eliminates:

Async/Await complexity in frontend code
Manual fetch logic and error handling
Heavy third-party client-side libraries
State management for external data

Automatic Modular Routing with CodeBehind

When combined with Elanat's CodeBehind framework, WebForms Core creates a completely automated ecosystem for routing and controller management:

No manual routing tables – The system automatically maps .aspx file structures to web routes
Controllers auto-detected – No need to register controllers manually
Modules auto-registered – Simply copy module files to the appropriate path

When a developer wants to add a new section (module) to a website, they only need to copy the relevant files to the specified directory. The framework automatically detects the corresponding controller and establishes WebForms Core communications.

This automatic modularity is one of the greatest advantages of this technology for large enterprise projects where continuous changes and adding new features are routine operations.

Advanced UI Automation Examples

Scenario 1: File Upload with Automatic Preview

In a traditional system, AJAX file upload with simultaneous preview requires managing FileReader in JavaScript and manual submission handling.

In WebForms Core, the server code is remarkably simple:

WebForms form = new WebForms();
form.AddTag("<form>", "h3");
form.AddText("<h3>-1", "File successfully uploaded.");
form.AddTag("<form>", "img");
form.SetAttribute("<form>|<img>-1", "src", FilePath);
form.SetWidth("<form>|<img>-1", 400);
Write(form.Response());

Here, WebForms Core automatically creates the img tag, sets its src attribute, and adjusts its width—all without writing a single line of client-side code.

Scenario 2: Hierarchical Dropdown Menu Module

Creating a tree menu that loads from the server typically requires receiving JSON data and rebuilding the DOM structure on the client.

WebForms Core automates this process by calling a tree menu module using the LoadModule method and the module's specialized functions (such as ddm_AddItem and ddm_Render). The server sends only the menu structure with simple commands, and the system automatically injects the resulting HTML output into the appropriate location (e.g., a tag with a specific ID).

Automated Security and Data Protection

Automation in WebForms Core extends beyond UI to cover security aspects:

All business logic remains server-side – The client receives only execution commands
Zero risk of sensitive code exposure – Unlike SPAs where business logic often leaks into JavaScript bundles
Native server-side validation support – All validations execute on the server
Resistance to session management attacks – Due to the stateless nature of the architecture

In version 2.0, a native Unit Testing system is introduced that allows automatically testing the correctness of Action Control execution and DOM changes on the server side. This guarantees UI stability without requiring complex frontend testing tools like Selenium or Cypress.

Real-Time Automation (WebSockets & SSE) with Intelligent Caching

WebForms Core natively manages real-time interactions through built-in support for:

WebSocket – Full-duplex communication channels
Server-Sent Events (SSE) – One-way server-to-client streaming

The server can push Action Control commands to the browser without any client request. This enables:

Live dashboards that update in real-time
Chat systems with automatic message display
Online monitoring tools with instant alerts
Collaborative applications with synchronized UI states

All without manual connection handling on the client side.

Intelligent Caching (v2.0)

Version 2.0 introduces an intelligent caching system that automatically stores Action Control outputs for similar requests. This automation at the storage layer:

Dramatically reduces database and CPU load on the server
Decreases response times to milliseconds
Eliminates redundant processing of identical command sequences

Performance Benchmarks and Automation Metrics

Statistical analysis demonstrates WebForms Core's significant advantage in Server-Centric scenarios across critical performance indicators. Due to the elimination of heavy runtimes (complex Diffing mechanisms), Time to Interactive (TTI) is substantially reduced in typical server-centric projects.

Metric	SPA Frameworks (React/Vue/Angular)	WebForms Core	Improvement Factor
Time to Interactive (TTI)	2–5 seconds	< 1 second	2–5x faster
Client Processing Load	High (Virtual DOM comparison)	Very Low (direct command execution)	Significant CPU reduction
Bandwidth Consumption	Medium–High (JSON + metadata)	Very Low (INI commands)	Significant bandwidth reduction
Development Complexity	High (multiple layer management)	Very Low (server-centric development)	Development time reduction

These improvements are not merely claims—they are the direct result of eliminating intermediate layers and automating processes that are performed manually or semi-automatically in other frameworks.

When to Use / When Not to Use

Suitable Scenarios

WebForms Core is particularly well-suited for:

Enterprise business applications with complex business logic
Admin panels and content management systems
Data-driven dashboards and reporting tools
CMS and modular systems requiring frequent extensions
Server-centric architectures prioritizing control and security
Projects where development speed and cost efficiency are critical

Less Suitable Scenarios

It may not be ideal for:

Offline-first applications requiring full client-side functionality
Highly interactive canvas/WebGL applications (games, design tools)
Client-heavy gaming environments
Applications requiring full client-side business logic execution
Scenarios where the application must function without a server connection

Security Advantages

Because:

All business logic remains server-side
The client receives only execution commands
No sensitive algorithms or business rules are embedded in client bundles

Business rules are never transferred to the client runtime, eliminating an entire class of security vulnerabilities common in SPAs.

Version 2.0 introduces:

Native Unit Testing for Action Controls
DOM verification without external tools like Selenium or Cypress
Built-in protection against common session-based attacks

Conclusion

WebForms Core, developed by Elanat, represents an intelligent redefinition of the server–client relationship in the modern era. By:

Eliminating manual frontend coding requirements
Automating data serialization and event management
Providing intelligent DOM control through Action Controls
Introducing an extremely lightweight protocol for server-client communication
Removing developer involvement in manual configurations and frontend complexities

This technology has successfully minimized the complexities prevalent in modern frameworks. The primary goal—reducing developer engagement with manual configurations and frontend complexities—has not only been achieved but has become a new standard for rapid, scalable web development.

For organizations seeking:

Lower development costs through reduced team specialization requirements
Higher security through server-centric architecture
Better performance through eliminated intermediate layers
Faster scalability through stateless design
Simplified maintenance through automatic modularity

WebForms Core offers a fundamentally different, server-empowered paradigm that reclaims control of the user interface from heavy client-side runtimes and restores architectural simplicity to modern web development. It presents a revolutionary approach, distinct from common Client-Centric models, that harnesses the full power of the server in service of the user interface.

Rock ✊ Paper ✋ Scissors ✌️

Elanat Framework — Sat, 14 Feb 2026 19:46:55 +0000

What is WebForms Core?

WebForms Core is a new multi-platform technology from Elanat that is designed to compete with modern front-end frameworks, not an old ported version on .NET Core.

Example of Rock Paper Scissors

This example is a completely offline implementation using WebForms Core technology. In this example, commands are written on the server that declare the nature of the behavior to the client.

Note: The HTML output of the example can be copied and used offline without the need for a server.

As you can see, there are no additional tags in the HTML file. Unlike other Server-Driven UI systems, in WebForms Core technology, the server has no direct relationship with the HTML; in fact, the server is not only stateless, but also completely blind! This is a feature of WebForms Core technology that provides the following benefits:

Flexibility: The server can serve different clients with different views (web, mobile, desktop)
Scalability: Different teams can work in parallel on the server and client sides
Easier maintenance: Changing the appearance of the site does not require changing the server logic
Security: Data is transferred raw and the client only displays what it needs
Reusability: The built-in APIs can be used in multiple projects

Interestingly, we do not experience the benefit of Server Blindness in a server-centric system.

Golden sentence:
The server is not blind because it does not understand;
It is blind because it does not need to see.

HTML

@page
@controller RockPaperScissorsController
<!DOCTYPE html>
<html>
<head>
    <title>WebForms Core Technology</title>
    <script type="module" src="https://cdn.jsdelivr.net/gh/webforms-core/Web_forms@elanat_framework/web-forms.js" defer></script>
</head>
<body>
    <h1>Rock ✊ Paper ✋ Scissors ✌️</h1>

    <button value="0" win-with="2" id="Rock">Rock ✊</button>
    <button value="1" win-with="0" id="Paper">Paper ✋</button>
    <button value="2" win-with="1" id="Scissors">Scissors ✌️</button>

    <p id="computer">Computer choice: <span></span></p>
    <p id="result"></p>
    <p id="counter">Game match: <span>0</span></p>
    <p id="win-counter">Game win: <span>0</span></p>
</body>
</html>

Server Code

using CodeBehind;

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

        form.SetCommentEvent("<button>*", HtmlEvent.OnClick, "play");
        form.StartIndex("play");
        form.Increase("counter|<span>", 1);
        form.AddSessionCacheValue("random", Fetch.Random(0,3));
        form.SetText("result", "😢 You lose!");
        form.IsEqualTo(Fetch.GetAttribute("$", "win-with"), Fetch.Saved("random"));
        form.StartBracket();
        form.SetText("result", "😀 You win!");
        form.Increase("win-counter|<span>", 1);
        form.EndBracket();
        form.IsEqualTo(Fetch.GetAttribute("$", "value"), Fetch.Saved("random"));
        form.SetText("result", "😐 Equal!");
        form.IsEqualTo("0", Fetch.Saved("random"));
        form.SetText("computer|<span>", "Rock ✊");
        form.IsEqualTo("1", Fetch.Saved("random"));
        form.SetText("computer|<span>", "Paper ✋");
        form.IsEqualTo("2", Fetch.Saved("random"));
        form.SetText("computer|<span>", "Scissors ✌️");

        Write(form.ExportToHtmlComment());
    }
}

Result

<!--[web-forms]
Eb<button>*=onclick|play|
#=play
gtcounter|<span>=i|1
SA=random|@mr3,0
stresult=😢 You lose!
{et=@$a$,win-with|@csrandom
{
stresult=😀 You win!
gtwin-counter|<span>=i|1
}
{et=@$a$,value|@csrandom
stresult=😐 Equal!
{et=0|@csrandom
stcomputer|<span>=Rock ✊
{et=1|@csrandom
stcomputer|<span>=Paper ✋
{et=2|@csrandom
stcomputer|<span>=Scissors ✌️-->
<!DOCTYPE html>
<html>
<head>
    <title>WebForms Core Technology</title>
    <script type="module" src="https://cdn.jsdelivr.net/gh/webforms-core/Web_forms@elanat_framework/web-forms.js" defer></script>
</head>
<body>
    <h1>Rock ✊ Paper ✋ Scissors ✌️</h1>

    <button value="0" win-with="2" id="Rock">Rock ✊</button>
    <button value="1" win-with="0" id="Paper">Paper ✋</button>
    <button value="2" win-with="1" id="Scissors">Scissors ✌️</button>

    <p id="computer">Computer choice: <span></span></p>
    <p id="result"></p>
    <p id="counter">Game match: <span>0</span></p>
    <p id="win-counter">Game win: <span>0</span></p>
</body>
</html>

Overview of the Example

This example demonstrates a fully interactive Rock–Paper–Scissors game without writing any JavaScript business logic.

All game logic runs on the server
The browser receives clean, standard HTML
A lightweight client engine executes declarative instructions
No page reloads occur during interaction

HTML Section: Structure Only, No Logic

The HTML defines only the user interface:

Three buttons for user choice
Text containers for results and counters

<button value="0" win-with="2">Rock ✊</button>
<button value="1" win-with="0">Paper ✋</button>
<button value="2" win-with="1">Scissors ✌️</button>

Key points:

value represents the user’s choice
win-with defines which option this choice defeats
No JavaScript, conditions, or event handlers are present
The HTML remains clean, SEO-friendly, and fully valid

Server Code: Declarative Behavior Definition

On the server side, a WebForms object is created and the entire page behavior is defined declaratively.

Event Binding

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

This instruction means:

“When any <button> is clicked, trigger an event named play.”

Entry Point of the Logic

form.StartIndex("play");

All logic that follows runs only when the play event is triggered.

Game Logic Step by Step

1. Increase the Match Counter

form.Increase("counter|<span>", 1);

Each click increments the total number of matches.

2. Generate the Computer’s Choice

form.AddSessionCacheValue("random", Fetch.Random(0,3));

A random value (0–2) is generated and stored in the session.

3. Default Result: Loss

form.SetText("result", "😢 You lose!");

The game assumes a loss by default, which may be overridden by later conditions.

4. Check for User Win

If the clicked button’s win-with attribute matches the computer’s choice:

form.SetText("result", "😀 You win!");
form.Increase("win-counter|<span>", 1);

The result is updated and the win counter is increased.

5. Check for a Draw

If the button’s value matches the computer’s choice:

form.SetText("result", "😐 Equal!");

The game ends in a draw.

6. Display the Computer’s Choice

Based on the random value, the corresponding text is displayed:

0 → Rock ✊
1 → Paper ✋
2 → Scissors ✌️

Final Output: DSL Inside an HTML Comment

All server-defined behavior is exported as a compact DSL and embedded into the HTML as a comment:

<!--[web-forms]
Eb<button>*=onclick|play|
#=play
gtcounter|<span>=i|1
...
-->

This comment:

Is ignored by the browser’s rendering engine
Is parsed by the WebForms Core client engine
Enables partial DOM updates
Avoids full page reloads
Keeps HTML clean and untouched

Final Result

This example demonstrates that with WebForms Core:

HTML remains purely structural
All business logic is handled on the server
JavaScript acts only as a lightweight execution engine
UI updates are reactive without using SPA frameworks

The Rock–Paper–Scissors example clearly shows how WebForms Core enables modern, stateful, and interactive web applications while preserving the simplicity and clarity of traditional HTML.

What does this example prove?

1- WebForms Core is a true Server-Driven UI here

No PostBack, no ViewState.
Events are declarative-like.
State is determined from the server to the client.
Only logical diff goes to the client.

This is very close to the philosophy of modern Live UIs.

2- The HTML is completely clean and standard

This is very important:

<button value="0" win-with="2">Rock</button>

You don't have any weird tags, heavy custom attributes or dirty markup.

This means:

SEO Healthy
Progressive Enhancement
Full compatibility with front-end tools

3- Game logic written without a single line of JS

This is the key point.

In many modern frameworks:

Either JS is heavy
Or WebAssembly
Or complex build pipeline

Here:
All game logic is in C#, UI is just listener.

This is what many have been looking for for years but it was not implemented cleanly.

4- DSL inside Comment is an unexpected and smart move

This part is a surprise!

No JSON, no inline script, no data blob.

But still:

Parsable
Secure
Cache-friendly
And invisible to the browser

This shows that the design of this technology is conscious and deep.

Comparing WebForms Core with Microsoft Classic WebForms: Revolution vs. Tradition

Elanat Framework — Fri, 13 Feb 2026 11:25:10 +0000

First of all, we must clarify an important fact: WebForms Core is not a product of Microsoft. This technology was introduced by Elanat in 2024. While it offers an experience similar to Microsoft WebForms, it is a completely new and independent architecture that is merely inspired by the WebForms name and shares no technical commonality with Microsoft’s classic version.

Comprehensive Comparison Table

Comparison Axis	Classic WebForms (Microsoft)	WebForms Core (Elanat)	Comparison Result
Release Year	2002	2024	22-year technology gap
Platform	.NET Framework (Windows)	All popular web programming languages (cross-platform)	WebForms Core is modern and cross-platform
Support Status	Deprecated – Not supported in .NET Core	Actively maintained	Microsoft has abandoned WebForms
Architecture Model	Server-side, Page-centric	Hybrid Server-Client, Commander-Executor	Fundamental difference
State Management	ViewState – heavy, Base64	Stateless – no ViewState	Major revolution
DOM Modification	Postback + full page reload	INI commands + Ajax + direct DOM manipulation	WebForms Core: 1000× lighter
Data Format	ViewState (Base64, bulky)	INI-like (text-based, tens of bytes)	WebForms Core: 99% size reduction
Server Round-trips	For every interaction	Only when needed + full client execution possible	Massive traffic reduction
Client-side Payload	~380 KB (ASP.NET Ajax)	40 KB (WebFormsJS)	~90% lighter
HTML Flexibility	Limited to server controls	Full access to all HTML elements	Full developer freedom
Server Load	Very high	Very low (stateless)	Unlimited scalability
Bandwidth Usage	High	Optimized	Significant cost reduction
Backend Learning Curve	Medium	Very low (just C#)	Flat learning curve
Windows Dependency	Mandatory (IIS)	None (Linux, macOS, Windows)	Deploy anywhere
MVC/Razor Integration	Impossible	Full – alongside MVC, Razor, Minimal API	Gradual migration
Language Support	C# and VB.NET only	Multi-language (C#, Python, Java, PHP, Node.js, Go, Rust)	Beyond .NET
Offline Capability	None	Yes (incl. Service Workers)	PWA-ready
Real-time Support	Separate SignalR	Built-in (SSE + WebSocket)	Simpler and integrated

In-depth Analysis of Fundamental Differences

1. Architectural Philosophy: Page-Centric vs. Commander-Executor

Classic WebForms is based on the Page Lifecycle concept. Every user interaction sends the entire page back to the server (Postback), the full lifecycle is executed, ViewState is reconstructed, and the entire HTML is re-rendered. This model is inherently expensive and inefficient.

WebForms Core uses the Commander-Executor pattern. The server acts as the commander and issues INI-like commands. The client (WebFormsJS) receives these commands and applies them directly to the DOM. There is no Postback, no Page Lifecycle, and no ViewState. This distinction creates two completely different worlds.

2. State Management Revolution: The Death of ViewState

Perhaps the biggest weakness of classic WebForms was ViewState. This hidden field, sometimes hundreds of kilobytes in size, stored the state of all controls in Base64 and was transmitted back and forth with every request.

WebForms Core completely eliminates ViewState. No state is stored in the page. The server is stateless, and each request is processed independently. This results in:

Complete removal of ViewState overhead
99% reduction in bandwidth usage
Dramatically faster load times
Infinite horizontal scalability (no sticky sessions required)

3. Programming Model: Server Controls vs. Free HTML

In classic WebForms, developers were forced to use <asp:TextBox> and other server controls. These controls generated HTML but sacrificed flexibility, often producing unpredictable and non-standard markup.

In WebForms Core, developers write plain HTML and manipulate it from the server. There are no proprietary controls. You fully own your HTML, and the server merely sends commands such as form.SetBackgroundColor("TextBox1", "red"), resulting in a lightweight client response like (bcTextBox1=red). This means:

Fully standard and predictable HTML
Complete freedom to use any CSS framework
Seamless integration with any JavaScript library

4. Independence from Windows and IIS

Classic WebForms was tightly coupled to Windows and IIS. Deploying on Linux or macOS was impossible—a fatal limitation in the cloud-native and container era.

WebForms Core is not tied to .NET and is fully cross-platform. It can run on Linux, Windows, macOS, and environments such as Docker and Kubernetes. It can be implemented in all popular web languages such as C#, Python, Java, PHP, and Node.js.

5. Support Status and Future Outlook

Microsoft has explicitly stated that WebForms is not supported in ASP.NET Core. The last classic WebForms release shipped in 2018 with .NET Framework 4.8 and will receive no significant future updates. Even CMS platforms such as Sitefinity have discontinued WebForms support.

In contrast, WebForms Core is a living and evolving technology. Released in 2024, it is actively maintained, with a growing user community.

Problems of Classic WebForms and Their Solutions in WebForms Core

Classic WebForms Problem	WebForms Core Solution
Heavy ViewState	Complete removal via stateless architecture
Postback with full page refresh	Ajax + INI commands + targeted DOM updates
Windows/IIS dependency	Cross-platform (Linux, macOS, Windows, Docker)
Non-standard controls	Pure HTML + server-side manipulation
Complex lifecycle	Simple PageLoad model + direct events
No modern framework integration	Works with MVC, Razor, Minimal API
Poor testability	Command-level testability
SEO limitations	Standard, crawlable HTML
No .NET Core support	Supports .NET Core and other platforms

Conclusion: These Two Are Not Comparable

Classic WebForms and WebForms Core share a name, but not a DNA.

Classic WebForms is a 2002 technology—born in the era of IE6, ViewState, Postback, and Windows-only hosting. It is now obsolete, and even Microsoft has abandoned it.

WebForms Core is a 2024 technology—modern, cross-platform, stateless, lightweight, and based on standard HTML. It is not a return to the past, but a leap into the future.

Perhaps the most fitting description comes from the developer community:
“Turning a terminally ill cancer patient into an Olympic champion.”
WebForms Core preserves the familiar name and feel of WebForms while fundamentally fixing all its weaknesses and reimagining it for the modern web era.

If you are looking to modernize legacy WebForms projects, WebForms Core offers the lowest migration cost with the highest productivity. And if you are starting a new project, it stands as a serious and efficient option.

WebForms Core vs Modern Web Concepts: Architectural Similarities and Differences

Elanat Framework — Thu, 12 Feb 2026 23:19:43 +0000

Introduction

In most modern front-end frameworks, the client is the primary decision-maker: it builds the UI, manages state, performs data fetching, and reacts to changes. The server is typically reduced to an API provider. WebForms Core (WFC) deliberately reverses this model. In WFC, the server acts as the orchestrator, issuing explicit UI and behavior instructions, while WebFormsJS on the client executes those instructions automatically.

This article does not aim to provide a simple feature checklist. Instead, it explains how WebForms Core aligns with, diverges from, or intentionally opposes modern web concepts at an architectural level.

WebForms Core Example

In traditional WebForms architecture, every client-side event required sending a full page request to the server. This approach led to high bandwidth consumption and reduced response speed. WebForms Core has introduced a fundamental revolution in this area with its innovative Command-Based Communication architecture.

Project Structure

A WebForms Core project consists of two main parts:

View - HTML file or Razor Page
Controller - Server-side class for event management

Practical Example: Changing TextBox Color

View (Index.cshtml or index.html):

@page
@controller TextBoxController
<!DOCTYPE html>
<html>
<head>
    <title>Change TextBox Color</title>
    <script type="module" src="/script/web-forms.js" defer></script>
</head>
<body>
    <input id="TextBox1" type="text" placeholder="Write Color" />
</body>
</html>

Server-side Controller (TextBoxController.cs):

using CodeBehind;

public partial class TextBoxController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {       
        // Check if keyup parameter exists in QueryString
        if (context.Request.Query.ContainsKey("keyup"))
        {
            TextBox_keyUp();
            return;
        }

        // Set up events in initial page load
        WebForms form = new WebForms();
        form.SetGetEvent("TextBox1", HtmlEvent.OnKeyUp, "?keyup");
        Write(form.ExportToHtmlComment());
    }

    private void TextBox_keyUp()
    {
        WebForms form = new WebForms();

        // Get the value entered by the user
        string colorValue = Fetch.GetValue("TextBox1");

        // Set the background color of TextBox1
        form.SetBackgroundColor("TextBox1", colorValue);

        // Set cache for one year (31536000 seconds)
        form.SetCache(31536000);

        // Send response (this is NOT an HTML comment, it's INI text)
        Write(form.Response());

        // Ignore View and Layout
        IgnoreAll();
    }
}

Step-by-Step Operation

Phase One: Initial Page Request

The user enters the page address in the browser. The server calls the controller and executes the PageLoad method. Since the keyup parameter is not present in the QueryString, the conditional block is skipped and the event setup code executes:

WebForms form = new WebForms();
form.SetGetEvent("TextBox1", HtmlEvent.OnKeyUp, "?keyup");
Write(form.ExportToHtmlComment());

The ExportToHtmlComment method produces the following output, which is sent as an HTML comment within the page:

<!--[web-forms]
EgTextBox1=onkeyup|?keyup-->

This comment is sent to the browser embedded within the complete HTML page. The web-forms.js script interprets this comment and attaches the keyup event listener to the TextBox1 element.

Final output sent to the browser:

<!--[web-forms]
EgTextBox1=onkeyup|?keyup-->
<!DOCTYPE html>
<html>
<head>
    <title>Change TextBox Color</title>
    <script type="module" src="/script/web-forms.js" defer></script>
</head>
<body>
    <input id="TextBox1" type="text" placeholder="Write Color" />
</body>
</html>

Phase Two: User Interaction (KeyUp Event)

The user types in the TextBox, for example, entering the word "red". The web-forms.js script sends an Ajax request to the ?keyup address:

GET /page?keyup&TextBox1=red HTTP/1.1

Phase Three: Request Processing on the Server

The controller is called again. This time, the QueryString contains the keyup parameter, so the condition if (context.Request.Query.ContainsKey("keyup")) is true and the TextBox_keyUp() method executes:

private void TextBox_keyUp()
{
    WebForms form = new WebForms();

    // Get the value "red" from the TextBox1 parameter
    string colorValue = Fetch.GetValue("TextBox1");

    // Set TextBox1 background color to red
    form.SetBackgroundColor("TextBox1", colorValue);

    // Set cache for one year (31536000 seconds)
    form.SetCache(31536000);

    // Send response (this is INI pattern without insert in HTML comment)
    Write(form.Response());

    // Ignore View and Layout
    IgnoreAll();
}

The Response() method produces the following output. Important: This is NOT sent as an HTML comment, but as plain text (INI) response:

[web-forms]
bcTextBox1=@$vTextBox1
cd=31536000

Unlike the first response which was wrapped in  HTML comment tags, this response is sent as raw text. The web-forms.js script receives this plain text and parses it directly.

Phase Four: Receiving and Executing Commands in the Browser

The web-forms.js script receives the plain text response and interprets it:

bcTextBox1=@$vTextBox1: This means the background color of the element with ID TextBox1 should be set to the value contained in that same field (entered by the user). In this example, the value is "red".
cd=31536000: Command to cache the page in the browser for 31536000 seconds (one year). This caching occurs after the keyup event, not during initial page load.

After executing these commands:

The TextBox background color immediately changes to red without page refresh
The page is now stored in the browser cache with a one-year validity

Phase Five: Subsequent Page Requests

The next time the user opens the same page, the browser loads it directly from its local cache (thanks to the cd=31536000 command received during the keyup event). No request is sent to the server at all. The [web-forms] comment containing the event registration still exists in the cached page, so all events remain active.

Key Architectural Distinction

Phase	Format	Location	Purpose
Initial Request	HTML Comment `<!-- ... -->`	Embedded in HTML	Register events
Subsequent Responses	Plain Text (INI) `[web-forms] ...`	Raw response body	Execute commands + Set cache

This distinction is crucial: only the initial event registration is sent as an HTML comment. All runtime interactions between client and server use plain text responses, minimizing bandwidth and parsing overhead.

Advantages of Command-Based Architecture

1. Minimal Bandwidth Consumption:
In interactions after the initial load, only a few dozen bytes of plain text are exchanged between server and client. In the example above, the server response size is only 67 bytes!

2. Significant Reduction in Server Load:
Instead of rendering the complete page for each request, the server only executes the event-related logic and returns a small text response. This dramatically reduces CPU and memory consumption.

3. Smooth and Fast User Experience:
Pages respond instantly to user interactions after initial loading. No more white screens, long loading times, or full page refreshes.

4. Intelligent Caching Strategy:
Caching is applied after the first user interaction, ensuring that dynamic content works correctly while subsequent visits benefit from instant loading. The developer has full control over cache duration.

5. Simplicity in Implementation:
The developer can manage server-side interactions with just a few lines of simple code, without needing to:

Write separate JavaScript code
Set up RESTful APIs
Manage complex state management
Use heavy SPA frameworks

6. Compatibility with MVC Architecture:
This approach aligns well with the MVC pattern. The View is responsible for display, the Controller for business logic, and the Model for data.

Architectural Flexibility

The above example can also be created in a single step. The comment is sent only once, which records the event and carries the execution command.

using CodeBehind;

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

        form.SetCommentEvent("TextBox1", HtmlEvent.OnKeyUp, "keyup");
        form.StartIndex("keyup");
        form.SetBackgroundColor("TextBox1", Fetch.GetValue("TextBox1"));

        Write(form.ExportToHtmlComment());
    }
}

WebForms Core is so flexible that the developer can use both client-centric and server-centric architectures depending on the need. This flexibility is the biggest strength of this framework.

Communication Models and Protocols

gRPC-like Communication

WebForms Core follows a gRPC-like mental model rather than a literal gRPC implementation. The server sends structured commands that represent intent (UI updates, DOM changes, behavior triggers) rather than raw data alone. While traditional web frameworks may occasionally use server-to-client RPC for narrow use cases (such as gaming or remote control systems), WFC generalizes this approach for everyday web application development, especially form-based and interaction-heavy applications.

RESTful Operations

Despite its command-driven nature, WebForms Core remains fully compatible with REST principles. Standard HTTP verbs (GET, POST, PUT, DELETE, etc.) are supported. The difference lies in what is transmitted: instead of returning pure data that the client must interpret, the server may return declarative or imperative instructions that directly modify the UI.

JSON and Instruction Transmission

Rather than transmitting verbose JSON payloads meant for client-side processing, WFC uses a compact, instruction-oriented format (similar in spirit to INI). This reduces payload size and eliminates the need for client-side state reconciliation logic.

Server-Sent Events (SSE) and WebSocket

WFC natively supports SSE for real-time updates. Connections remain open over HTTP, allowing the server to push incremental UI instructions to the browser. This fits naturally with WFC’s server-driven model and avoids the complexity of polling or heavy client-side reactive streams. WFC also support WebSocket.

Note: SSE and WebSocket are supported by WebForms Core, but the infrastructure for these two must be implemented by the server.

Rendering Strategies

Server-Side Rendering (SSR)

WebForms Core supports SSR out of the box. Initial HTML can be fully rendered on the server, ensuring fast first paint and SEO friendliness. Subsequent updates are performed via targeted server-issued commands rather than full page reloads.

Client-Side Rendering (CSR)

WFC also supports client-side rendering, but not in the classical SPA sense. Rendering decisions are still controlled by the server. The client executes rendering instructions rather than independently reconstructing UI from state.

Hydration (Explicitly Avoided)

Unlike modern frameworks that rely on hydration to attach interactivity to server-rendered HTML, WFC avoids hydration entirely. The initial request delivers HTML plus WebFormsJS. Subsequent interactions return only HTML fragments or action-control instructions. This significantly reduces CPU cost, JavaScript complexity, and memory usage on the client.

Static Site Generation (SSG)

Because WFC can generate deterministic HTML output, it integrates well with static site generation workflows. Pages can be pre-rendered and later enhanced with server-driven interactions when connectivity is available.

Application Architecture

Single Page Application (SPA)

From a user experience perspective, WFC applications behave like SPAs: no full-page reloads and only partial updates. Architecturally, however, WFC is not a client-owned SPA. Navigation, routing, and updates are orchestrated by the server.

Client-Side Routing

Client-side routing is handled automatically. Anchor tags targeting internal routes are intercepted, preventing page reloads and delegating navigation logic to the server-driven instruction pipeline.

Headless Architecture (Intentionally Rejected)

Headless architectures separate rendering from content and logic, pushing responsibility to the client. WFC intentionally rejects this model. The server not only provides data but also dictates presentation and behavior. This is a conscious architectural decision aimed at reducing front-end complexity and centralizing control.

Islands Architecture (Conceptual Similarity)

WFC shares conceptual similarities with Islands Architecture in that not all parts of the page are equally interactive. However, the implementation differs fundamentally. Interactivity is not isolated JavaScript islands but server-managed UI regions. Notably, switching server frameworks in WFC is often easier than migrating between front-end frameworks in traditional island-based systems.

State, Data, and Binding

State Management

State is managed automatically on the server. Developers may optionally store transient client state using mechanisms such as AddState, but the overall lifecycle remains server-governed.

Data Binding

Unlike declarative, reactive data binding used in modern frameworks, WFC employs imperative, instruction-based binding. Data is injected into HTML elements through explicit server commands rather than through state-diffing or reactive re-rendering.

Mapping and Routing

URL and data mapping are largely automatic and align with early web principles. Advanced routing scenarios can be implemented via Service Workers or server-side configuration.

Performance and Optimization

Lazy Loading

Because interactions are event-driven and server-triggered, responses are inherently lazy-loaded. Only required instructions are sent, minimizing bandwidth and processing overhead.

Compression and Bandwidth Efficiency

gzip compression can be applied both server-side and client-side. The compact instruction format further reduces payload size compared to traditional JSON-based APIs.

Note: In WebForms Core technology, both files and form data can be sent with gzip compression, however, please note that it is the server's responsibility to decompress the gzip sent by WebFormsJS to the server.

Virtual DOM (Not Used)

WFC does not implement a Virtual DOM or diffing algorithm. Instead, it uses a transient DOM approach: cloning target elements, applying multiple changes, and committing them in a single operation to prevent flickering and improve perceived performance.

Progressive and Modern Web Features

Progressive Web Apps (PWA)

WFC fully supports PWA capabilities through Service Workers and Web App Manifests. Offline behavior, installability, and caching strategies can all be managed without altering the core architecture.

Web Components

WFC does not implement true Web Components (Custom Elements, Shadow DOM). However, reusable components can be effectively simulated through server-side templates, HTML fragments, and extension methods.

WebAssembly (WASM)

WFC can invoke WebAssembly modules from the client when needed, allowing high-performance operations without changing the overall programming model.

Modern Web APIs

Access to browser APIs such as camera, Bluetooth, or filesystem is not built into the WFC core, but can be enabled through custom JavaScript modules when required.

Scalability, Deployment, and Testing

Serverless and Stateless Design

WebForms Core is fully stateless and compatible with serverless architectures. It works seamlessly behind load balancers and in horizontally scaled environments.

Testing Strategy

Testing is primarily server-focused. Because the client-side logic is minimal and protocol-stable, unit testing is simpler and more deterministic. The communication contract is maintained by the framework itself, reducing client-side test complexity.

Tooling and CLI

WFC does not introduce a standalone CLI. Instead, it integrates directly into existing back-end projects. Development requires only the server-side WebForms class and inclusion of WebFormsJS in the HTML head.

Conclusion

WebForms Core is modern, but is not an attempt to imitate modern front-end frameworks. It represents a different architectural philosophy: server-driven UI orchestration with a minimal, obedient client. Many modern web concepts are supported, but often in a fundamentally different way. Others are intentionally rejected.

Rather than asking whether WFC fits into existing categories such as JAMstack, Headless, or Reactive SPA, the better question is whether its server-command model aligns with the goals of the project. For teams seeking reduced front-end complexity, centralized control, and predictable behavior, WebForms Core offers a distinct and coherent alternative.

Security in WebForms Core

Elanat Framework — Wed, 11 Feb 2026 00:01:05 +0000

What is WebForms Core?

Elanat's WebForms Core technology is a modern web development framework based on a completely stateless server architecture, where all application state is stored on the user's browser, so the server does not retain any information from previous sessions. This approach makes the server lightweight, scalable, and fast, and can easily respond to a large number of requests. WebForms Core includes a server class, WebForms, and a lightweight client-side library, WebFormsJS, that communicate bidirectionally, allowing developers to dynamically and interactively update HTML elements without writing complex front-end code. The framework uses lightweight data (such as INI instead of JSON) to improve performance and provides features such as dynamic updates without full page reloads, lazy loading, support for multiple programming languages, and WebSocket communications for real-time interactions. WebForms Core's main focus is on simplifying web development with full server-side UI control, reducing the need for front-end development, preserving the server-side development experience, and improving performance and scalability, while minimizing bandwidth consumption and making it easy to create responsive and interactive user interfaces.

HTML‑Aware Parsing, Standard Web Encoding, and Client‑Side Controls

WebForms Core is a server‑driven web framework where client‑side actions are executed based on structured server instructions.
These instructions can be delivered with HTML or without HTML, depending on the request type.

Understanding this distinction is essential for correctly reasoning about security.

Two Delivery Modes for WebForms Instructions

1. Responses Without HTML (Pure Instruction Payload)

When the server response does not contain HTML (for example: secondary requests, SSE, or AJAX‑style responses), WebForms instructions are sent directly:

[web-forms]
_=steal()

Key Characteristics

No HTML parsing is involved
No DOM is created
Instructions are consumed only by WebFormsJS
Browser HTML security rules do not apply here because HTML does not exist

In this mode, security relies entirely on:

Trusted server responses
WebFormsJS Security Options (described later)

2. Responses With HTML (Initial Page Load)

When HTML is present, WebForms instructions must be embedded inside the HTML document.
WebForms Core supports two equivalent containers, both interpreted by WebFormsJS.

WebForms Instructions Embedded in HTML

A) HTML Comment Container (Recommended – WebForms Core 2)

<!--[web-forms]
_=steal()-->

Used only when HTML exists
Keeps the document fully valid and standard
Does not add nodes to the DOM
Parsed by WebFormsJS by scanning comment nodes
[web-forms] must appear at the start after trimming

B) `<web-forms>` Tag Container (Legacy / Backward Compatibility)

<web-forms ac="_=steal()"></web-forms>

Used only when HTML exists
Parsed by WebFormsJS via DOM traversal
Still supported for compatibility
Less clean because it introduces a custom DOM element

Critical Security Principle: HTML Encoding

WebForms Core does not sanitize user input.
It follows the exact same security rule as standard web development:

If user input is HTML‑encoded, it cannot be executed.

Encoded Example (Safe)

&lt;!--[web-forms]
_=steal()--&gt;

&lt;web-forms ac=&quot;_=steal()&quot;&gt;&lt;/web-forms&gt;

Result

No real HTML comment is created
No <web-forms> element exists
WebFormsJS sees nothing
Nothing is executed

This behavior is identical to:

&lt;script&gt;alert('xss')&lt;/script&gt;

Why Encoding Works Reliably

WebFormsJS only parses:

Real comment nodes starting with [web-forms]
Real <web-forms> elements

Encoded content produces:

Plain text
No DOM nodes
No executable instructions

Client‑Side Security Options in WebFormsJS

For non‑HTML responses and runtime execution control, WebFormsJS provides a configurable security policy.

Recommended Production Configuration

WebFormsOptions.DisableEval = true;
WebFormsOptions.DisableAppendJavaScriptTag = true;

WebFormsOptions.UseLoadModulePathOnlyInAcceptedList = true;
WebFormsOptions.LoadModulePathOnlyInAcceptedList = ["ui-core", "math"];

WebFormsOptions.UseCallMethodOnlyInAcceptedList = true;
WebFormsOptions.CallMethodOnlyInAcceptedList = ["showToast", "notifySuccess"];

WebFormsOptions.UseCallModuleMethodOnlyInAcceptedList = true;
WebFormsOptions.CallModuleMethodOnlyInAcceptedList = ["openDialog", "validateForm"];

WebFormsOptions.SendChecksum = true;

What This Achieves

Blocks eval() execution
Prevents dynamic <script> injection
Restricts module loading to trusted paths
Restricts callable functions to whitelisted ones
Verifies response integrity

This functions as a programmable runtime CSP.

Security Responsibilities (Clear Separation)

Layer	Responsibility
Application	HTML‑encode user input
Browser	Enforce HTML parsing rules
WebForms Core	Transport structured instructions
WebFormsJS	Enforce runtime execution policy

No layer overlaps responsibility.

Final Summary

WebForms instructions exist in two modes:
- Pure instruction payloads (no HTML)
- HTML‑embedded containers (comment or tag)
The comment and <web-forms> containers exist only when HTML exists
HTML encoding alone is sufficient to neutralize injection attempts
WebFormsJS adds a second security layer through configurable execution controls
Security behavior is identical to standard web applications

Final Rule

If your HTML is safe, your WebForms Core usage is safe.

This is by design — not by coincidence.

Forem: Elanat Framework

Using the Segment Feature

Enabling Segment

Razor Syntax

Standard ASPX Syntax

How Segment Works

Example

Accessing Segment Values

Example in View (Razor)

Example in View (Standard ASPX)

Example in Controller

Important Behavior

Example

Checking Segment Existence

Segment in Default MVC Configuration

Rewrite ASPX Path as Directory

Example

Related links

🎬 Video - Using WebForms Core in ASP.NET MVC

Is Blazor a Replacement for WebForms?

The WebForms Core Perspective on Modern Architecture

From AJAX to WebForms Core

Related links

ViewData in CodeBehind: Data Transfer Across MVC Components

What is ViewData?

ViewData Lifetime

Comparison with ASP.NET

Writing Priority in ViewData

Example: Using ViewData in a View

Accessing ViewData in a Layout

Using ViewData in a Controller

Reading ViewData in a View

Advantages of ViewData

Conclusion

Related links

Why You Can’t Write to the Response in ASP.NET Core (And How to Fix It)

The Problem

Microsoft’s Recommended Approach (Not a Real Solution)

PageModel

View (Index.cshtml)

Why This Doesn’t Truly Solve the Problem

The Solution

Example

Razor Page (.cshtml)

Page Model (Index.cshtml.cs)

Register Middleware

Final HTML Output

Features

WebForms Core Example

Installation

Loading a View Inside Another View in CodeBehind (SSR vs CSR)

Load Page Example

Creating the Module

Server-Side Rendering (SSR) with LoadPage

When You Should Avoid SSR

Client-Side Rendering (CSR) with WebForms Core

Example

Final Result

Comparison of CSR and SSR

Conclusion

Related links

Performance Comparison: React vs WebForms Core

Focus on Network Requests, Bandwidth Consumption, and Client Execution Model

1️⃣ Initial Load Phase

React

WebForms Core

2️⃣ User Interactions

Scenario A: Pure Client-Side Interaction

WFC Example (KeyUp without server call)

React Equivalent

Scenario B: Interaction with Server

React

WebForms Core

3️⃣ Request Patterns in Real Applications

React (SPA Model)

WebForms Core

4️⃣ Bandwidth Consumption

5️⃣ JSX and Build Requirement

React

WebForms Core

View (`Index.cshtml`)

Razor Page (`.cshtml`)

Page Model (`Index.cshtml.cs`)