DEV Community: Elanat Framework

WebForms Core 2.2 Development Has Begun

Elanat Framework — Thu, 24 Sep 2026 22:54:13 +0000

A New Stateless Architecture for Server-Orchestrated UI

Unlike many server-driven UI approaches, including Blazor Server, WebForms Core introduces a fundamentally different architectural model: server-orchestrated UI built on a stateless server and server-defined UI structure. While Blazor Server maintains a stateful server-side circuit for each connected browser context, WebForms Core does not require the server to maintain a persistent component tree, render tree, or mirrored DOM state for each user. Instead, the server defines UI operations through the WebForms class and generates commands that WebFormsJS executes against the actual HTML document in the browser. This creates a clean separation between server-defined UI structure and client-side DOM execution, while preserving the stateless nature of the server architecture. The result is a lightweight and scalable model in which the server orchestrates the interface without becoming the permanent owner of its browser-side state. WebForms Core therefore approaches Server-Driven UI from a different direction: not by keeping the UI alive on the server, but by describing and orchestrating UI transformations from a stateless server.

WebForms Core 2.2 is focused on taking the server-orchestrated UI model to a higher level. The goal is not simply to add more commands, but to provide better mechanisms for rendering, state management, data transformation, formatting, arithmetic operations, and extensibility.

The direction of 2.2 is to make complex UI operations more expressive while keeping the WebForms Core architecture server-oriented, HTML-native, and independent of a separate frontend framework.

A More Expressive WebForms Model

WebForms Core uses a server-side WebForms class to generate commands that are executed by WebFormsJS in the browser:

Server
   ↓
WebForms
   ↓
Commands
   ↓
WebFormsJS
   ↓
HTML DOM

With 2.2, the focus is moving toward higher-level operations.

Instead of requiring developers to construct every transformation from small DOM commands, WebForms Core can increasingly perform formatting, text processing, arithmetic calculations, rendering operations, state detection, and other transformations directly within the WebForms execution model.

Isolated DOM Operations

One of the new capabilities in WebForms Core 2.2 is Isole.

Isole provides a high-level abstraction for working with the Transient DOM. It automatically performs the transient DOM initialization and completion around a group of operations.

This removes the need to manually manage the underlying StartTransientDOM and EndTransientDOM operations.

The result is a simpler way to isolate a complex group of DOM transformations while keeping them within the existing WebForms execution hierarchy.

Rendering and State Management

Rendering and state management are among the most important architectural directions in WebForms Core 2.2.

Complex UI updates are rarely just a single DOM operation. A rendering process may involve multiple transformations, temporary states, repeated template binding, state detection, and potentially restoring the previous state.

WebForms Core 2.2 is therefore introducing mechanisms that allow these operations to be treated as part of a larger rendering process.

Snapshot and Rollback

Snapshot and rollback provide a mechanism for preserving and restoring the HTML state of an element.

A snapshot can preserve the outerHTML of a target before a transformation. The element can then be modified, rendered, or repeatedly bound to a template. If necessary, the previous state can be restored.

Conceptually:

Current DOM State
    ↓
Snapshot
    ↓
Transform
    ↓
New DOM State
    ↓
Rollback
    ↓
Previous DOM State

This is particularly useful for complex rendering scenarios where several operations need to work against the same original state.

It also provides a foundation for higher-level rendering operations in which snapshot and rollback do not need to be explicitly managed by the developer.

Hash-Based State Detection

WebForms Core 2.2 also introduces GetTagHash.

The operation generates a hash from the HTML representation of a tag. The hash can be stored and later compared with a new hash to determine whether the HTML state has changed.

This provides a lightweight mechanism for detecting UI state changes without requiring the server to maintain a mirror of the browser DOM.

Conceptually:

HTML
 ↓
GetTagHash
 ↓
Hash
 ↓
Store
 ↓
Later
 ↓
GetTagHash
 ↓
Compare

This capability can become useful for state validation, conditional rendering, optimization, and future rendering mechanisms.

Rendering Without Mirroring the DOM

These mechanisms follow an important principle of WebForms Core.

The server does not need to maintain a complete representation of the browser's DOM.

Instead, the server can describe a transformation, while WebFormsJS performs that transformation against the actual HTML document in the browser.

This keeps the architecture server-orchestrated without turning the server into a permanent DOM state manager.

Formatting Data

WebForms Core 2.2 introduces formatting operations for cached and saved values.

This allows common formatting tasks to be performed directly inside the WebForms execution model.

For example:

4200
↓
4,200

A time value can also be normalized:

23:1:8
↓
23:01:08

Formatting can use regular expressions, making the mechanism useful for both simple formatting and more advanced text transformations.

For example:

(\d)(?=(\d{3})+$)

can be used to transform a numeric string into a thousands-separated representation.

This removes the need for repetitive conditional operations for common formatting scenarios.

Arithmetic Operations

WebForms Core 2.2 also brings arithmetic operations directly into the WebForms command model.

The supported operations include:

+
-
*
/
%
//
**

These operations make it possible to perform calculations directly on values used by WebForms commands.

For example, a value can be increased, decreased, multiplied, divided, processed with modulo or integer division, or used in an exponentiation operation without requiring custom JavaScript.

This is particularly useful when arithmetic is part of a larger server-orchestrated UI operation.

Text Operations

Text operations are another significant part of WebForms Core 2.2.

Instead of requiring developers to repeatedly save intermediate values and manually manipulate strings, WebForms Core can perform common string operations directly within the WebForms execution flow.

Operations include capabilities such as:

Substring
TextBefore
TextAfter

and other string transformations.

These operations make it possible to extract and transform parts of values directly in WebForms commands.

For example, a value can be processed by extracting a specific substring, obtaining the text before or after a specified value, and then passing the result to another operation.

This creates a much more expressive data-transformation model:

Fetch
  ↓
Text Operation
  ↓
Arithmetic
  ↓
Format
  ↓
Render

The significance is not the individual string methods themselves. The important part is that data transformation becomes a native part of the WebForms execution model.

Regex-Based Tag Selection

WebForms Core 2.2 also introduces the ability to select tags using regular expressions against their HTML representation.

This provides another mechanism for locating elements when conventional selectors are not sufficient.

A developer can work with the HTML representation of elements and use a regular expression to identify matching tags for further operations.

This extends the selection capabilities of WebForms Core beyond conventional CSS-oriented targeting.

Comments and Debugging

A Comment capability has also been introduced.

It allows developers to place comments within the generated WebForms command structure.

This is useful when inspecting generated Action Controls and understanding why a particular sequence of commands exists.

For complex WebForms classes, comments can make the generated command structure easier to understand and debug.

The feature is intentionally simple, but it becomes increasingly useful as WebForms classes contain more sophisticated rendering and transformation logic.

Middleware

WebForms Core 2.2 is also moving toward a middleware-based extension mechanism.

The purpose is to allow developers to add specialized JavaScript capabilities without modifying the WebFormsJS core.

For example:

form.UseMiddleware("/js/image-quality.js");

A middleware can participate in a processing stage and modify data before it continues through the normal execution flow.

For example, an image-quality middleware could process uploaded images before they are sent:

FormData
   ↓
Image Quality Middleware
   ↓
XMLHttp.send()

This makes specialized capabilities possible as independent modules.

Image processing is only one example. Similar middleware modules could provide compression, client-side transformations, specialized controls, or other browser capabilities.

The important point is that middleware extends the existing WebForms Core architecture rather than introducing a separate execution model.

From Commands to Operations

One of the broader goals of WebForms Core 2.2 is to increase the abstraction level of the WebForms language.

A WebForms class can increasingly express operations such as:

Format
Arithmetic
Text Processing
Rendering
State Detection
Snapshot
Rollback
Middleware

rather than implementing every behavior as a collection of low-level DOM commands.

This makes the WebForms class more expressive while preserving the underlying Commander-Executor architecture.

A Server-Orchestrated Rendering Architecture

WebForms Core 2.2 continues the evolution of WebForms Core as a Server-Orchestrated UI technology.

The server remains responsible for describing UI operations through the WebForms class and generated commands.

WebFormsJS remains responsible for executing those commands against the browser's actual HTML DOM.

The architecture can therefore be represented as:

Server
   ↓
WebForms Class
   ↓
Server Commands
   ↓
WebFormsJS
   ↓
HTML DOM

The new capabilities in 2.2 add higher-level layers around this architecture:

Data
 ↓
Transformation
 ↓
Formatting
 ↓
Rendering
 ↓
State Detection
 ↓
DOM Execution

This allows WebForms Core to handle increasingly complex interactive interfaces without requiring a separate frontend application or a client-side virtual representation of the UI.

The Direction of WebForms Core 2.2

WebForms Core 2.2 is still under development, so additional capabilities and API refinements may be introduced during development.

However, the direction is already clear.

The focus is moving from individual DOM manipulation toward a more complete model for server-orchestrated rendering, data transformation, state management, and extensibility.

The objective is to make complex interactive web applications easier to build while keeping the architecture:

Server-oriented
HTML-native
Stateless at the application architecture level
RESTful
Compatible with HTTP, WebSocket, and SSE
Independent of a separate frontend framework
Extensible through WebForms and WebFormsJS

WebForms Core 2.2 is not simply another collection of commands.

It is an effort to build a more expressive foundation for Server-Orchestrated UI.

Elanat CMS Will Be Retired After Version 2.2: Introducing Gloria, a New Generation CMS

Elanat Framework — Wed, 23 Sep 2026 20:46:24 +0000

Elanat has made an important decision regarding the future of its content management system.

Elanat CMS 2.2 will be the final version of Elanat CMS. After version 2.2, Elanat CMS will be permanently retired and no new versions will be released.

This decision does not mean that Elanat is leaving the CMS space. Instead, we have decided to begin a new CMS project with a new name: Gloria.

Gloria will be a new generation CMS built from the ground up using the latest versions of .NET, the CodeBehind Framework, and WebForms Core technology.

Why Are We Retiring Elanat CMS?

Elanat CMS has become a very large software system.

The current project contains approximately:

2,894 files
1,667 folders

The size of the project is not itself a problem. In fact, this size reflects the amount of functionality and structure that has been developed in Elanat CMS over the years.

The real challenge is the cost of making fundamental architectural changes to an already large system.

Elanat CMS was originally designed around an SSR architecture with vanilla JavaScript for client-side interaction. The system also contains many structures that were appropriate for its original architecture and development period.

Changing fundamental parts of such a large system is possible. We could continue modifying Elanat CMS and gradually replace its internal structures.

However, we reached the point where continuing to modify the existing system would require increasingly complex changes.

Instead of continuously modifying an old architecture, we decided that it would be more appropriate to build a new system from the beginning.

From Elanat CMS to Gloria

The new system will be called Gloria.

Gloria will not simply be a new version of Elanat CMS.

It will be a new CMS project with a new architectural foundation.

The goal is to use the latest versions of .NET together with the latest capabilities of the CodeBehind Framework and WebForms Core.

This will allow us to redesign the internal architecture instead of carrying every historical implementation decision from Elanat CMS into the new system.

One important example is data access.

Some parts of Elanat CMS rely on structures such as Stored Procedures. In Gloria, we want to move toward modern approaches such as ORM-based data access where appropriate.

This is one of the reasons why a clean rewrite is more suitable than attempting to transform the existing system piece by piece.

Gloria Will Continue the Elanat CMS Philosophy

Although Gloria will be a new system, it will not abandon the concepts that made Elanat CMS what it is.

Some important concepts and structures will continue in Gloria.

The add-on-oriented architecture will remain an important part of the new system.

The concepts of components, add-ons, and the way different parts of the system are organized will also continue to influence Gloria.

Naming conventions and several structural ideas from Elanat CMS will be carried forward.

Therefore, Gloria should not be understood as an unrelated CMS.

It is better understood as the next generation of the Elanat CMS direction, implemented with a new technical foundation.

The Elanat Ecosystem

Elanat's ecosystem currently consists of three major technologies and products:

CodeBehind Framework
WebForms Core
Elanat CMS

CodeBehind is the modern full-stack framework developed by Elanat under ASP.NET Core. It supports multiple development patterns and provides the foundation on which Elanat CMS was built.

WebForms Core is Elanat's server-side UI manipulation technology. It introduces a server-side WebForms class and a browser-side WebFormsJS runtime for executing commands against the HTML DOM.

Elanat CMS was built on the CodeBehind Framework and developed as a large, modular CMS with an add-on-oriented architecture.

The new direction brings these technologies closer together.

Gloria will be built on the latest generation of CodeBehind and WebForms Core.

This means that the new CMS will be developed using the technologies that Elanat has been building and improving independently over recent years.

Why a New Name?

We deliberately chose a new name instead of simply calling the project "Elanat CMS 3".

There is an important reason for this.

Gloria will not be a normal major version upgrade.

It will be a new system created from the foundation up.

Calling it Elanat CMS 3 would suggest that the project is simply continuing the existing codebase with another major version.

That would not accurately describe what we are doing.

Elanat CMS 2.2 is the end of the existing Elanat CMS project. Gloria is the beginning of a new CMS project.

A Clearer Name and Identity

There was also another consideration behind the decision to introduce a new name.

The name Elanat CMS is closely associated with Elanat, the organization and technology ecosystem behind the project. Over time, this similarity sometimes created confusion between the name of the CMS itself and the name Elanat as the broader ecosystem.

Elanat is no longer limited to a single CMS. Its ecosystem now includes CodeBehind, WebForms Core, and Elanat CMS, each representing a different part of the technology stack.

For this reason, introducing a distinct name for the next-generation CMS will also provide a clearer identity for the product.

The new name, Gloria, separates the identity of the CMS from the identity of the Elanat ecosystem while preserving the project's connection to its history.

Gloria will therefore have its own product name, while remaining part of the Elanat ecosystem.

The Elanat Logo Will Continue

Although Gloria will have a new name, the project will retain the Elanat CMS logo.

The logo is part of the visual identity and history of the project, and we want that connection to remain visible.

Gloria therefore represents a new technical beginning while preserving part of the identity that came from Elanat CMS.

In this sense, the relationship is simple:

Elanat CMS → Gloria

The name changes.

The architecture evolves.

The experience gained from Elanat CMS remains.

And the development continues under the Elanat ecosystem.

What Happens to Elanat CMS 2.2?

Elanat CMS 2.2 is the final version.

There will be no Elanat CMS 2.3.

There will be no Elanat CMS 3.

After version 2.2, the Elanat CMS project will be considered retired.

The existing project will remain part of Elanat's open-source history, but active development will move to Gloria.

The decision also means that we will not attempt to transform the existing Elanat CMS codebase into Gloria through an endless series of migrations.

Instead, Gloria will start from a clean foundation.

A New Beginning

Large software projects accumulate history.

That history can be valuable because it contains years of development experience, architectural experiments, solutions to real problems, and ideas that have proven useful.

But history can also make fundamental redesign increasingly difficult.

Elanat CMS has reached a point where we believe a new beginning is the more appropriate engineering decision.

We could continue modifying the existing system.

Instead, we chose to build something new.

Gloria will take the lessons, concepts, structures, and experience of Elanat CMS and combine them with the modern technologies developed by Elanat.

The target is a CMS that is substantially more modern, easier to evolve, and better aligned with the current Elanat technology stack.

Repository Transition

The transition to Gloria also includes a change in the project's repository structure.

The new Gloria project is being developed in a separate repository:

Gloria on GitHub

The existing Elanat CMS repository will be archived:

Elanat CMS on GitHub

Archiving the repository does not mean that the history of Elanat CMS will be removed. The repository will remain available as an archived record of the project and its development history, while active CMS development moves to Gloria.

This separation is intentional.

Elanat CMS represents the previous generation of the CMS, while Gloria represents a new implementation built around the current Elanat technology stack.

Elanat CMS 2.2 is the final release. The Elanat repository will be archived, and active CMS development will continue in the Gloria repository.

From the Past to the Next Generation

Elanat CMS was an important part of the development of the Elanat ecosystem.

It helped establish concepts such as an add-on-oriented architecture, modular system design, components, and a CMS structure capable of supporting a wide range of functionality.

Today, the ecosystem has evolved.

CodeBehind has become a modern ASP.NET Core framework.

WebForms Core is a server-side UI manipulation technology for working with HTML through server-generated commands.

The next step is to bring these technologies together in a new CMS.

That CMS will be Gloria.

Elanat CMS 2.2 marks the end of one chapter.

Gloria will begin the next one.

Go WebAssembly Meets WebForms Core 2.1

Elanat Framework — Wed, 23 Sep 2026 07:49:08 +0000

WebAssembly is often used to move application logic into the browser and build increasingly large client-side applications.

WebForms Core takes a different approach.

Instead of making WebAssembly the frontend architecture, WebAssembly can be used as an execution layer inside a server-orchestrated UI architecture.

In this example, Go is compiled to WebAssembly and participates in the WebForms Core execution flow.

The examples in this article are designed to demonstrate the server-orchestrated capabilities of WebForms Core. They could also be configured differently so that some operations do not require server participation.

The general architecture is:

Server → WebForms → Commands → WebFormsJS → HTML DOM

With WebAssembly, the architecture can also include a local execution layer:

Server → WebForms → WebAssembly → WebForms Commands → WebFormsJS → HTML DOM

The important idea is that WebAssembly does not have to replace the UI architecture. It can become another execution capability inside that architecture.

What is WebForms Core?

WebForms Core is a server-orchestrated UI technology that allows the server to generate commands for manipulating the browser DOM and controlling UI behavior.

Its architecture can be summarized as:

Server → WebForms → Commands → WebFormsJS → HTML DOM

WebForms Core does not require a separate frontend project, component framework, JSX, or a virtual DOM.

It works with standard HTML and lets the WebForms class generate UI operations.

WebFormsJS is responsible for interpreting and executing the resulting WebForms Core commands in the browser.

With WebAssembly support, selected methods can also execute locally in the browser.

This creates an important distinction:

WebAssembly can provide an execution layer without becoming the UI architecture.

Go WebAssembly

Go is a general-purpose programming language with built-in WebAssembly support.

Go can compile code directly to the WebAssembly target used by modern browsers:

GOOS=js
GOARCH=wasm

A Go WebAssembly module can execute application logic in the browser while communicating with JavaScript through the Go WebAssembly runtime.

In this example, Go is used together with WebForms Core 2.1.

The Go module can:

execute numerical methods
receive parameters from JavaScript
create WebForms Core commands
return WebForms Core responses
generate HTML
participate in WebForms Core events

The important detail is that the Go code in this example does not manipulate the browser DOM directly.

Instead, it can use the WebForms class to generate a WebForms Core response.

The response can then be interpreted by WebFormsJS.

Creating the Go WebAssembly Project

A Go WebAssembly project can be created as a normal Go module.

A typical project can contain:

your-project-name/
    go.mod
    main.go
    webformscore/
    build.bat

The go.mod file defines the Go module:

module your-project-name

go 1.25.5

The webformscore directory contains the Go implementation of the WebForms Core API.

The WebAssembly build can be automated with a Windows batch file:

@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

The resulting WebAssembly module is:

webforms-go.wasm

Go WebAssembly Runtime

Unlike a minimal WebAssembly module that can be instantiated directly through the WebAssembly JavaScript API, Go WebAssembly applications use the Go browser runtime.

The runtime is provided by:

wasm_exec.js

The WebForms Core application therefore keeps both files available to the browser:

/web-assembly/go/
    webforms-go.wasm
    wasm_exec.js

webforms-go.wasm contains the compiled Go application.

wasm_exec.js provides the JavaScript-side Go runtime required to execute the Go WebAssembly module.

WebForms Core can load this runtime automatically when a Go WebAssembly method is requested.

Install the Go Package

The Go implementation of WebForms Core can be installed as a Go module.

CLI:

go get github.com/webforms-core/go

github.com/webforms-core/go provides the WebForms Core API used by the Go implementation.

WebFormsJS Installation via Package

WebFormsJS is available through npm.

JavaScript in npm: webformsjs on npm

CLI:

npm install webformsjs

WebFormsJS is also available directly from the following GitHub repository:

WebFormsJS GitHub Repository

If you install WebFormsJS through npm, the package can be imported and used directly in your JavaScript project.

Alternatively, the source files can be obtained from the GitHub repository.

Using WebForms Core from Go

The interesting part of this example is that the Go WebAssembly code uses the WebForms Core API directly.

The main.go file contains the exported JavaScript-facing methods:

package main

import (
    "syscall/js"

    WebFormsCore "your-project-name/webformscore"
)

func add(this js.Value, args []js.Value) interface{} {
    a := int32(args[0].Int())
    b := int32(args[1].Int())

    return a + b
}

func setData(this js.Value, args []js.Value) interface{} {
    inputPlace := args[0].String()
    text := args[1].String()
    backgroundColor := args[2].String()
    fontSize := args[3].String()

    form := WebFormsCore.New()

    form.SetText(inputPlace, text)
    form.SetBackgroundColor("-", backgroundColor)
    form.SetFontSize("-", fontSize)

    return form.Response()
}

func getHtml(this js.Value, args []js.Value) interface{} {
    return "<marquee>Tag From Wasm!</marquee>"
}

func main() {
    js.Global().Set("add", js.FuncOf(add))
    js.Global().Set("setData", js.FuncOf(setData))
    js.Global().Set("getHtml", js.FuncOf(getHtml))

    select {}
}

There are three methods used by the WebForms Core example:

add
setData
getHtml

Each demonstrates a different way a Go WebAssembly method can participate in the WebForms Core execution model.

`add`

The add method performs a simple calculation:

add(10000, 3)

It returns:

The method receives two numeric arguments through the JavaScript-to-Go WebAssembly interface.

This demonstrates a basic WebAssembly method that returns a value.

However, WebForms Core can also use WebAssembly methods that produce UI responses.

`setData`

The setData method receives four strings:

inputPlace
text
backgroundColor
fontSize

It creates a WebForms object and generates a WebForms Core response:

form := WebFormsCore.New()

form.SetText(inputPlace, text)
form.SetBackgroundColor("-", backgroundColor)
form.SetFontSize("-", fontSize)

return form.Response()

The important detail is that the Go method is not returning JavaScript DOM operations.

It is generating a WebForms Core response.

That response can then be interpreted by WebFormsJS.

`getHtml`

The third method returns HTML:

<marquee>Tag From Wasm!</marquee>

The HTML can then be placed into the browser through a WebForms Core event.

This demonstrates that a WebAssembly method can also return content that participates in the WebForms Core output flow.

The WebForms Class in Go

The important architectural detail is that WebForms is not a browser component.

The Go code uses it as a command generator.

For example:

form := WebFormsCore.New()

form.SetText(inputPlace, text)
form.SetBackgroundColor("-", backgroundColor)
form.SetFontSize("-", fontSize)

return form.Response()

The resulting response is interpreted by WebFormsJS in the browser.

Therefore, the flow becomes:

Go
 ↓
WebForms
 ↓
WebForms Core Commands
 ↓
WebFormsJS
 ↓
HTML DOM

Go does not need to know how WebFormsJS applies the commands to the browser DOM.

That responsibility belongs to WebFormsJS.

This separation allows the Go WebAssembly layer to focus on application logic and command generation while WebFormsJS remains the browser-side UI runtime.

Go WebAssembly and JavaScript

Go WebAssembly uses syscall/js to communicate with the browser.

In this example, the Go methods are registered as JavaScript functions:

js.Global().Set("add", js.FuncOf(add))
js.Global().Set("setData", js.FuncOf(setData))
js.Global().Set("getHtml", js.FuncOf(getHtml))

This makes the functions available to the WebAssembly execution layer.

For example, after the Go runtime is initialized, the JavaScript environment can access:

add
setData
getHtml

WebFormsJS can therefore invoke these methods as part of the WebForms Core execution flow.

The important distinction is that JavaScript provides the browser integration required by the Go WebAssembly runtime, while WebFormsJS provides the WebForms Core browser-side execution environment.

Using Go WebAssembly from WebForms Core

The server-side controller can invoke Go WebAssembly methods through the WebForms Core WASM API.

The controller is:

using CodeBehind;

public partial class WasmGOController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        string WasmPath = "/web-assembly/go/webforms-go.wasm"; 
        //string WasmPath = "/web-assembly/go/wasm_exec.js"; 

        WebForms form = new WebForms();

        form.AddText("<b>", Fetch.WasmMethod(WasmLanguage.GO, WasmPath, "add", [10000, 3]));

        form.SetWasmEvent("WasmEvent", HtmlEvent.OnClick, WasmLanguage.GO, WasmPath, "setData", ["h3Tag", "Text From Wasm", "lightgreen", "30px"]);
        form.SetWasmEvent("WasmEventWithOutput", HtmlEvent.OnClick, WasmLanguage.GO, WasmPath, "getHtml", [], "WasmHtmlOutput");

        Write(form.ExportToHtmlComment());
    }
}

The controller does not contain the Go implementation details.

It defines how the WebAssembly methods participate in the WebForms Core UI flow.

This is an important separation:

Server-side controller
        ↓
WebForms Core definition
        ↓
WebAssembly method
        ↓
WebForms response
        ↓
WebFormsJS

HTML

The page itself remains ordinary HTML:

@page
@controller WasmGOController
@layout "/layout.aspx"
@{
  ViewData.Add("title","GO Wasm");
}
<h3>GO Wasm</h3>
<b>GO WASM Result: </b>
<br>
<button id="WasmEvent">Wasm Event</button>
<br>
<h3 id="h3Tag">Wasm Tag Changing!</h3>
<button id="WasmEventWithOutput">Wasm Event With Output</button>
<p id="WasmHtmlOutput">Wasm Html Output</p>

There is no Go-specific markup.

There is no custom WebAssembly element.

There is no component declaration.

The HTML remains standard HTML.

WebForms Core can assign behavior to these existing HTML elements without requiring the page to be redesigned around WebAssembly.

The Interesting Part

The interesting part is not simply that Go can run inside WebAssembly.

The more important point is that a WebAssembly method can participate in the WebForms Core command architecture.

A Go method can return a normal value:

Go → Value

But it can also generate a WebForms Core response:

Go → WebForms → Commands → WebFormsJS → DOM

For example:

form.AddText(
    "<b>",
    Fetch.WasmMethod(
        WasmLanguage.GO,
        WasmPath,
        "add",
        [10000, 3]
    )
);

The add method is implemented in Go, but its result can be consumed by WebForms Core.

The second method is more interesting:

form.SetWasmEvent(
    "WasmEvent",
    HtmlEvent.OnClick,
    WasmLanguage.GO,
    WasmPath,
    "setData",
    ["h3Tag", "Text From Wasm", "lightgreen", "30px"]
);

When the button is clicked, WebFormsJS can invoke the Go WebAssembly method.

The method creates a WebForms response:

form := WebFormsCore.New()

form.SetText(inputPlace, text)
form.SetBackgroundColor("-", backgroundColor)
form.SetFontSize("-", fontSize)

return form.Response()

The response is then interpreted by WebFormsJS.

The resulting execution chain is:

HTML Event
    ↓
WebFormsJS
    ↓
Go WASM
    ↓
WebForms
    ↓
WebForms Core Response
    ↓
WebFormsJS
    ↓
DOM

This is different from simply calling a WebAssembly function and returning a number.

The WebAssembly method can become a producer of UI commands.

That is what allows Go WebAssembly to participate in the WebForms Core UI execution model.

WASM Event With Output

The third method demonstrates another possibility:

form.SetWasmEvent(
    "WasmEventWithOutput",
    HtmlEvent.OnClick,
    WasmLanguage.GO,
    WasmPath,
    "getHtml",
    [],
    "WasmHtmlOutput"
);

The Go method returns HTML:

func getHtml(this js.Value, args []js.Value) interface{} {
    return "<marquee>Tag From Wasm!</marquee>"
}

WebForms Core can then place the returned value into:

<p id="WasmHtmlOutput">Wasm Html Output</p>

This demonstrates that WebAssembly methods can participate directly in the WebForms Core output flow.

Where Does the Execution Take Place?

This architecture does not require every operation to execute on the server.

The server can generate the initial WebForms Core commands and define the UI behavior, while selected WebAssembly methods can execute locally in the browser.

For an interactive event, the flow can be:

Browser Event
    ↓
WebFormsJS
    ↓
Go WebAssembly
    ↓
WebForms Response
    ↓
WebFormsJS
    ↓
HTML DOM

This allows the application to keep a server-orchestrated UI model while selectively executing code locally in the browser through WebAssembly.

The examples in this article intentionally demonstrate this integration with WebForms Core. Other configurations can reduce or eliminate server participation for selected operations.

Go Is an Execution Layer

This example demonstrates an important distinction.

WebAssembly is not being used here to build a complete frontend application.

Go is being used as an execution layer.

The UI architecture remains:

HTML
  +
WebForms Core
  +
WebFormsJS

Go WebAssembly is inserted where local WebAssembly execution provides value:

                 WebForms Core
                      │
             ┌────────┴────────┐
             │                 │
       Server WebForms      Go WASM
                               │
                              Go

This allows the application to use WebAssembly selectively instead of moving the entire application into a WebAssembly frontend.

No Custom JavaScript Required for These UI Operations

In this example, the application does not need custom JavaScript business logic to perform these UI operations.

The Go method performs the computation or generates the WebForms Core response.

WebFormsJS remains the browser runtime responsible for executing the resulting commands.

Therefore, the flow is:

Go → WebForms Commands → WebFormsJS → DOM

rather than requiring a separate custom JavaScript layer between the Go code and the UI.

This separation keeps the WebAssembly layer independent from the application's browser-side DOM implementation.

Standard HTML Remains the UI

The Go example does not introduce a new component model.

The page still contains standard HTML:

<h3 id="h3Tag">Wasm Tag Changing!</h3>

and:

<button id="WasmEvent">Wasm Event</button>

The server assigns behavior to these existing elements.

This is one of the important characteristics of WebForms Core.

WebAssembly does not require the UI to be redesigned around WebAssembly components.

The HTML remains the UI, while WebForms Core and WebFormsJS provide the command and execution layers.

Go and WebForms Core

The Go implementation demonstrates that a WebAssembly language can use the same WebForms Core model as other supported languages.

The important relationship is:

Go
 ↓
WebForms Class
 ↓
Action Controls / Response
 ↓
WebFormsJS
 ↓
Browser DOM

The WebForms class acts as the bridge between application logic and WebForms Core command generation.

This makes the WebAssembly module more than an isolated computational library.

It can participate in the UI execution model.

WebAssembly Does Not Have to Replace the UI Architecture

A common approach to WebAssembly applications is to move a large portion of the frontend into the WebAssembly runtime.

WebForms Core takes a different approach.

WebAssembly can be introduced only where it provides value.

For example, an application can continue using:

standard HTML
server-side WebForms
WebFormsJS
server-generated commands

while selectively executing Go code through WebAssembly.

This makes WebAssembly an execution capability rather than a mandatory application architecture.

The result is a hybrid execution model in which the UI architecture remains based on HTML and WebForms Core while WebAssembly can provide additional local execution capabilities.

Go WebAssembly and WebFormsJS

Go provides the WebAssembly execution environment, while WebFormsJS remains responsible for browser-side UI execution.

A simple method can be written as:

func add(this js.Value, args []js.Value) interface{} {
    a := int32(args[0].Int())
    b := int32(args[1].Int())

    return a + b
}

The method executes inside the Go WebAssembly environment.

When combined with WebForms Core, the overall flow can be represented as:

Server
  ↓
WebForms
  ↓
WebAssembly Method
  ↓
Go
  ↓
WebForms Response
  ↓
WebFormsJS
  ↓
DOM

The browser therefore remains responsible for UI execution while Go provides a WebAssembly execution layer.

WebForms Core 2.1 and WebAssembly Languages

WebForms Core 2.1 allows the WebAssembly execution layer to work with different programming languages while keeping the UI command architecture unchanged.

In this example, Go provides the WebAssembly implementation.

The same architectural model can be used with other supported WebAssembly languages:

                 WebForms Core
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       Go WASM      C# WASM      Rust WASM
          │            │            │
          └────────────┼────────────┘
                       ↓
                  WebFormsJS
                       ↓
                      DOM

The WebAssembly implementation can change without requiring the HTML UI to be redesigned around a language-specific component model.

The UI command architecture remains the same.

Final Result

The final application combines four technologies:

CodeBehind
     ↓
WebForms Core 2.1
     ↓
Go WebAssembly
     ↓
WebFormsJS

Each layer has a different responsibility.

CodeBehind provides the server-side application environment.

WebForms Core provides the command-generation and UI orchestration model.

Go WebAssembly provides a local execution layer in the browser.

WebFormsJS provides the browser-side execution environment.

HTML remains the UI.

The result is a WebAssembly-enabled application model without requiring a separate WebAssembly frontend architecture.

Conclusion

Go WebAssembly does not have to become the frontend architecture.

With WebForms Core 2.1, Go can be used as a WebAssembly execution layer inside a server-orchestrated UI architecture.

The resulting model can be represented as:

Server → WebForms → WebAssembly → WebForms Commands → WebFormsJS → DOM

Go can perform computation, respond to browser events, generate WebForms Core responses, and participate in interactive UI operations.

At the same time, the application can continue using standard HTML and WebForms Core commands.

The key idea is simple:

WebAssembly can be an execution layer without becoming the UI architecture.

Rust WebAssembly with WebForms Core 2.1

Elanat Framework — Tue, 22 Sep 2026 21:28:01 +0000

What is WebForms Core?

WebForms Core is a modern multi-platform web technology from Elanat for building interactive HTML applications through server-defined commands and client-side command execution.

WebForms Core uses a server-oriented architecture in which the server defines UI behavior through commands, while a lightweight browser runtime executes those commands.

With WebForms Core 2.1 (WFC), WebAssembly can also be used as an execution layer within this architecture.

In this article, we will use Rust WebAssembly with WebForms Core and demonstrate two approaches:

Rust with wasm-bindgen
Raw WebAssembly using extern "C"

Both approaches can execute Rust code through WebForms Core.

More importantly, Rust code running inside WebAssembly can use the WebForms Core WebForms class to generate WebForms Core commands.

This creates a pipeline such as:

Rust
  ↓
WebAssembly
  ↓
WebForms
  ↓
WebForms Core Commands
  ↓
WebFormsJS
  ↓
Browser DOM

The WASM module executes in the browser, while the server-side WebForms class declares when and how the WASM method should be executed. The WASM method can then use the WebForms API to generate WebForms Core commands, which are executed by WebFormsJS in the browser.

Rust WebAssembly

Rust has first-class support for compiling code to WebAssembly.

A Rust project can target:

wasm32-unknown-unknown

For example:

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

The resulting WebAssembly module is generated under:

target/wasm32-unknown-unknown/release/

For example:

webformscore_wasm_test.wasm

This module can then be executed in the browser through WebForms Core's WebAssembly execution layer.

Rust in Crates.io

Rust in Crates.io (https://crates.io/crates/webformscore)

CLI

cargo add webformscore

Project settings

[dependencies]
webformscore = "#.#.#"

Two Rust WebAssembly Approaches

WebForms Core can work with different Rust WebAssembly execution models.

1. wasm-bindgen

The first approach uses:

use wasm_bindgen::prelude::*;

and:

#[wasm_bindgen]

The Rust project can then be processed by wasm-bindgen:

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

This produces JavaScript glue code and a WebAssembly module.

The resulting files include:

webformscore_wasm_test.js
webformscore_wasm_test_bg.wasm

WebForms Core can execute the generated JavaScript module through its JavaScript WASM executor.

The wasm-bindgen approach is useful when Rust code needs convenient JavaScript interoperability.

2. Raw WebAssembly

The second approach does not use wasm-bindgen.

Instead, Rust functions can be exported directly using:

#[no_mangle]
pub extern "C" fn

For example:

#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

The function is exported directly into the WebAssembly module.

There is no JavaScript glue code generated by wasm-bindgen.

The resulting architecture is:

Rust
  ↓
extern "C"
  ↓
Raw .wasm
  ↓
WebForms Core WASM Executor

This approach is particularly interesting for WebForms Core because the WASM module can expose a direct callable interface without depending on the wasm-bindgen JavaScript layer.

Creating the Rust Project

Create a Rust library project:

cargo new webformscore_wasm_test --lib

Enter the project:

cd webformscore_wasm_test

The project can use:

[package]
name = "webformscore_wasm_test"
version = "2.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
webformscore = "2.1.0"

The important dependency is:

webformscore = "2.1.0"

This makes the WebForms Core Rust implementation available inside the WebAssembly project.

Using WebForms Core from Rust

The Rust code can directly use the WebForms class:

use webformscore::WebForms;

For example:

let mut form = WebForms::new();

form.set_text("h3Tag", "Text From Wasm");
form.set_background_color("-", "lightgreen");
form.set_font_size("-", "30px");

form.response()

The Rust code does not directly manipulate the browser DOM.

Instead, it creates a WebForms Core response containing commands.

This preserves the same command-oriented architecture used by WebForms Core.

The Rust WASM module therefore does not need to know how WebFormsJS applies the commands to the DOM.

Rust with wasm-bindgen

The wasm-bindgen version is straightforward.

The complete Rust source can be written as:

use wasm_bindgen::prelude::*;
use webformscore::WebForms;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[wasm_bindgen]
pub fn set_data(
    input_place: String,
    text: String,
    background_color: String,
    font_size: String,
) -> String {
    let mut form = WebForms::new();

    form.set_text(&input_place, &text);
    form.set_background_color("-", &background_color);
    form.set_font_size("-", &font_size);

    form.response()
}

#[wasm_bindgen]
pub fn get_html() -> String {
    "<marquee>Tag From Wasm!</marquee>".to_string()
}

The important point is that the Rust methods can use:

WebForms

directly.

The WebAssembly method therefore does not need to manipulate the DOM itself.

It can generate a WebForms Core response instead.

Building the wasm-bindgen Module

Build the Rust WebAssembly module:

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

Then run:

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

The generated package contains the JavaScript glue required by the wasm-bindgen execution model.

The resulting structure is conceptually:

webformscore_wasm_test.js
webformscore_wasm_test_bg.wasm
webformscore_wasm_test.d.ts

The JavaScript file provides the JavaScript-facing interface for the Rust WebAssembly module.

Raw WebAssembly with Rust

Rust can also export functions directly without wasm-bindgen.

A simple function is:

#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

This function is exported directly by the WebAssembly module.

A complete Raw WASM example can be written as:

use std::ffi::CStr;
use webformscore::WebForms;

#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[no_mangle]
pub extern "C" fn alloc(size: usize) -> *mut u8 {
    let mut buffer = Vec::with_capacity(size);
    let ptr = buffer.as_mut_ptr();

    std::mem::forget(buffer);

    ptr
}

#[no_mangle]
pub extern "C" fn set_data(
    input_place: *const u8,
    text: *const u8,
    background_color: *const u8,
    font_size: *const u8,
) -> *const u8 {
    let input_place = unsafe {
        CStr::from_ptr(input_place as *const i8)
            .to_str()
            .unwrap()
    };

    let text = unsafe {
        CStr::from_ptr(text as *const i8)
            .to_str()
            .unwrap()
    };

    let background_color = unsafe {
        CStr::from_ptr(background_color as *const i8)
            .to_str()
            .unwrap()
    };

    let font_size = unsafe {
        CStr::from_ptr(font_size as *const i8)
            .to_str()
            .unwrap()
    };

    let mut form = WebForms::new();

    form.set_text(input_place, text);
    form.set_background_color("-", background_color);
    form.set_font_size("-", font_size);

    let response = form.response();

    let mut output = response.into_bytes();
    output.push(0);

    Box::into_raw(output.into_boxed_slice()) as *const u8
}

#[no_mangle]
pub extern "C" fn get_html() -> *const u8 {
    b"<marquee>Tag From Wasm!</marquee>\0".as_ptr()
}

This version has no:

use wasm_bindgen::prelude::*;

and no:

#[wasm_bindgen]

The functions are exported directly from the WebAssembly module.

Passing Strings to Raw WebAssembly

Primitive values such as:

i32

are straightforward:

pub extern "C" fn add(a: i32, b: i32) -> i32

Strings require an explicit memory representation.

In the Raw WASM example, WebForms Core passes strings into WebAssembly memory and the Rust code reads them using:

CStr::from_ptr(...)

For example:

let text = unsafe {
    CStr::from_ptr(text as *const i8)
        .to_str()
        .unwrap()
};

The Rust method can then use the resulting string normally:

form.set_text(input_place, text);

The response is returned through a pointer to UTF-8 data.

This represents a simple ABI suitable for direct WebAssembly execution.

Returning WebForms Core Responses

The most interesting part of the Raw WASM example is that set_data does not return a traditional application value.

It creates a WebForms Core response:

let mut form = WebForms::new();

form.set_text(input_place, text);
form.set_background_color("-", background_color);
form.set_font_size("-", font_size);

let response = form.response();

The response can then be returned to WebForms Core.

Therefore:

Rust WASM
    ↓
WebForms
    ↓
response()
    ↓
WebForms Core
    ↓
WebFormsJS
    ↓
Browser DOM

The Rust WebAssembly method effectively becomes another source of WebForms Core commands.

This is the central architectural idea of the example.

Using Rust WASM from WebForms Core

The server-side WebForms Core controller can declare a WASM method invocation that is executed by the browser.

For example:

using CodeBehind;

public partial class WasmRustController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        string WasmPath = "/web-assembly/rust/webformscore_wasm_test_bg.wasm";

        WebForms form = new WebForms();

        form.AddText(
            "<b>",
            Fetch.WasmMethod(
                WasmLanguage.Rust,
                WasmPath,
                "add",
                [10000, 3]
            )
        );

        form.SetWasmEvent(
            "WasmEvent",
            HtmlEvent.OnClick,
            WasmLanguage.Rust,
            WasmPath,
            "setData",
            ["h3Tag", "Text From Wasm", "lightgreen", "30px"]
        );

        form.SetWasmEvent(
            "WasmEventWithOutput",
            HtmlEvent.OnClick,
            WasmLanguage.Rust,
            WasmPath,
            "getHtml",
            [],
            "WasmHtmlOutput"
        );

        Write(form.ExportToHtmlComment());
    }
}

Both the wasm-bindgen and Raw WebAssembly examples use server-side WebForms Core code to demonstrate the power of its server-oriented architecture. However, server-side orchestration is not required by WebForms Core itself. These scenarios can also be configured to run without server-side WebForms code when server orchestration is not needed.

The same WFC API can therefore declare Rust WASM method calls.

The server does not need to know the internal implementation of the Rust method.

It only needs to specify:

WASM language
WASM path
method name
arguments

The server defines the execution behavior, while the browser executes the WASM module and processes the resulting WebForms Core response.

Three Rust WASM Methods

The example exposes three methods:

add
set_data
get_html

The first method returns a number:

add(10000, 3)

which produces:

The second method receives strings and generates a WebForms Core response:

set_data(
    "h3Tag",
    "Text From Wasm",
    "lightgreen",
    "30px"
)

The third method returns HTML:

get_html()

which produces:

<marquee>Tag From Wasm!</marquee>

This demonstrates that WebForms Core can use WASM methods for different kinds of operations:

returning values
generating WebForms Core commands
returning HTML

HTML

The HTML remains standard HTML:

@page
@controller WasmRustController
@layout "/layout.aspx"

@{
    ViewData.Add("title", "Rust Wasm");
}

<h3>Rust Wasm</h3>

<b>Rust WASM Result: </b>

<br>

<button id="WasmEvent">
    Wasm Event
</button>

<br>

<h3 id="h3Tag">
    Wasm Tag Changing!
</h3>

<button id="WasmEventWithOutput">
    Wasm Event With Output
</button>

<p id="WasmHtmlOutput">
    Wasm Html Output
</p>

There is no custom WebAssembly HTML element.

There is no special component syntax.

There is no Rust-specific DOM layer.

The page remains standard HTML.

The WASM Method as a Command Execution Source

Consider this:

form.SetWasmEvent(
    "WasmEvent",
    HtmlEvent.OnClick,
    WasmLanguage.Rust,
    WasmPath,
    "setData",
    ["h3Tag", "Text From Wasm", "lightgreen", "30px"]
);

WebForms Core declares that when the button is activated, a Rust WASM method should be executed.

The Rust method can then create:

let mut form = WebForms::new();

form.set_text(input_place, text);
form.set_background_color("-", background_color);
form.set_font_size("-", font_size);

and return the WebForms Core response.

The WASM method therefore becomes an execution source for WebForms Core commands.

The browser does not need a separate Rust-specific UI architecture.

WASM Event With Output

The same mechanism can return HTML:

#[no_mangle]
pub extern "C" fn get_html() -> *const u8 {
    b"<marquee>Tag From Wasm!</marquee>\0".as_ptr()
}

The server connects it to an output element:

form.SetWasmEvent(
    "WasmEventWithOutput",
    HtmlEvent.OnClick,
    WasmLanguage.Rust,
    WasmPath,
    "getHtml",
    [],
    "WasmHtmlOutput"
);

The returned HTML is then placed into:

<p id="WasmHtmlOutput">
    Wasm Html Output
</p>

This demonstrates that a Rust WASM method can also be used as a source of dynamic UI output.

One WebForms Core API, Different WASM Models

The WebForms Core API does not have to change when the WASM execution model changes.

The application can use:

Rust + wasm-bindgen

or:

Rust + Raw WebAssembly

while the WebForms Core invocation remains conceptually the same:

WasmMethod

The execution layer handles the differences between the WASM models.

This gives WebForms Core a unified way to work with different WebAssembly environments.

wasm-bindgen vs Raw WebAssembly

The two approaches have different characteristics.

Feature	wasm-bindgen	Raw WebAssembly
Rust API	High-level	Low-level
String handling	Mostly abstracted	Explicit memory handling
JavaScript glue	Generated	No `wasm-bindgen` glue
`.js` module	Yes	No
Direct `.wasm` loading	Possible with a compatible interface	Yes
ABI complexity	Mostly handled by wasm-bindgen	Developer-defined
Memory/ABI control	Mostly abstracted	Developer-defined
WebForms Core integration	Yes	Yes
Best suited for	General Rust WASM applications	Direct WASM execution

The wasm-bindgen approach is convenient when Rust needs a rich JavaScript interoperability layer.

The Raw WebAssembly approach is attractive when the goal is a directly callable WASM module with a developer-defined ABI.

Neither approach changes the WebForms Core command model.

WebForms Core Rust WASM Architecture

The resulting architecture can be viewed as:

                         Server
                           │
                           │ WebForms
                           ↓
                     WasmMethod
                           │
                           ↓
                    Browser Runtime
                           │
                  ┌────────┴────────┐
                  │                 │
                  ↓                 ↓
           wasm-bindgen        Raw WASM
                  │                 │
                  ↓                 ↓
             Rust WASM          Rust WASM
                  │                 │
                  └────────┬────────┘
                           ↓
                       WebForms
                           │
                           ↓
                  WebForms Core Response
                           │
                           ↓
                       WebFormsJS
                           │
                           ↓
                      HTML DOM

This shows the role of WebAssembly more clearly.

WebAssembly does not replace the WebForms Core execution model.

Instead, it provides another execution environment inside that model.

No Separate JavaScript Business Logic

One of the interesting properties of this example is that application behavior can be implemented in Rust without creating a separate JavaScript business-logic layer.

The Rust code contains the behavior:

let mut form = WebForms::new();

form.set_text(input_place, text);
form.set_background_color("-", background_color);
form.set_font_size("-", font_size);

form.response()

The HTML contains standard HTML:

<button id="WasmEvent">
    Wasm Event
</button>

And WebForms Core connects the two:

form.SetWasmEvent(
    "WasmEvent",
    HtmlEvent.OnClick,
    WasmLanguage.Rust,
    WasmPath,
    "setData",
    [...]
);

The Rust code does not need to search for the button, register a DOM event listener, or manually update the target element.

WebForms Core defines the interaction, while WebFormsJS executes the resulting commands in the browser.

Raw WebAssembly and wasm-bindgen Are Different

It is important to distinguish these two approaches.

A Raw WebAssembly module can expose functions directly:

module.wasm
     ↓
WebAssembly.instantiate()
     ↓
exported function

The wasm-bindgen approach introduces a generated JavaScript interoperability layer:

Rust
 ↓
wasm-bindgen
 ↓
generated JavaScript
 ↓
_bg.wasm
 ↓
Rust exported function

These are different execution models.

WebForms Core can provide an abstraction over both models while keeping the application-level WASM invocation consistent.

WebAssembly as an Execution Layer

This example demonstrates a broader idea.

WebAssembly does not necessarily have to represent an entire frontend application.

A WASM module can instead provide a specific execution capability.

For example:

WebForms Core
      ↓
Rust WASM
      ↓
Process data
      ↓
Generate WebForms Core response
      ↓
WebFormsJS
      ↓
Browser DOM

The Rust code can therefore perform computation, generate UI commands, or return values without becoming a complete client-side application framework.

This allows WebAssembly to participate in the existing WebForms Core command architecture.

Rust and WebForms Core

Rust is particularly interesting in this architecture because it can be compiled into WebAssembly while still using the WebForms Core API.

For example:

let mut form = WebForms::new();

form.set_text("h3Tag", "Text From Wasm");

The Rust code does not need to know how WebFormsJS internally executes the resulting command.

It only creates the WebForms Core response.

This separates:

Application execution

from:

Browser UI execution

The WASM module performs its computation and creates the desired WebForms Core response, while WebFormsJS remains responsible for applying commands to the HTML DOM.

Rust WASM Compared with Direct JavaScript DOM Manipulation

A conventional JavaScript approach might directly perform:

document.getElementById("h3Tag").textContent = "Text From Wasm";

The Rust WebAssembly approach demonstrated here does not need to manipulate the DOM directly.

Instead, it can produce WebForms Core behavior through:

WebForms

This means the Rust code participates in the same command architecture used by the rest of the WebForms Core application.

The UI execution remains centralized in the WebForms Core command pipeline.

WebForms Core 2.1

WebForms Core 2.1 extends the WebForms Core execution model with WebAssembly integration.

Rust is particularly interesting for this capability because it supports both:

wasm-bindgen

and:

Raw WebAssembly

The same WebForms Core application can therefore use Rust WASM as an execution layer while keeping its HTML and UI command model intact.

The important point is not simply that:

Rust can run in the browser.

The more interesting part is:

Rust running in WebAssembly can participate in the WebForms Core command architecture.

A WASM module can therefore become a computational or UI-command-producing execution environment without requiring the application to adopt a separate frontend architecture.

Final Architecture

The complete architecture can be summarized as:

                    Server
                      │
                      ↓
                  WebForms
                      │
                      ↓
                  WasmMethod
                      │
                      ↓
                  Browser
                      │
             ┌────────┴────────┐
             │                 │
             ↓                 ↓
      wasm-bindgen        Raw WebAssembly
             │                 │
             └────────┬────────┘
                      ↓
                    Rust
                      │
                      ↓
                  WebForms
                      │
                      ↓
          WebForms Core Response
                      │
                      ↓
                 WebFormsJS
                      │
                      ↓
                  HTML DOM

This makes Rust WebAssembly more than a way to run Rust code in the browser.

It becomes another execution environment capable of participating in the WebForms Core server-orchestrated command architecture.

The same model can therefore combine:

Rust
WebAssembly
Raw WebAssembly
wasm-bindgen
WebForms Core
WebForms Core commands
WebFormsJS
Standard HTML

without requiring the application to become a traditional JavaScript SPA.

Conclusion

Rust WebAssembly and WebForms Core provide an interesting combination.

With wasm-bindgen, Rust can expose a convenient WebAssembly API with JavaScript interoperability.

With Raw WebAssembly, Rust can expose functions directly through extern "C" using a developer-defined ABI.

Both approaches can participate in the WebForms Core execution model.

The result is a different way of thinking about WebAssembly:

WebAssembly does not have to replace the UI architecture. It can become an execution layer inside the UI architecture.

When that execution layer can directly use WebForms, Rust code can generate WebForms Core commands instead of implementing a separate client-side DOM architecture.

This extends the WebForms Core execution model from:

Server
  ↓
WebForms
  ↓
Commands
  ↓
WebFormsJS
  ↓
HTML DOM

to also support:

Server
  ↓
WebForms
  ↓
WasmMethod
  ↓
Rust WASM
  ↓
WebForms
  ↓
Commands
  ↓
WebFormsJS
  ↓
HTML DOM

This is one of the capabilities introduced by WebForms Core 2.1.

Build Interactive Web Pages with TypeScript and WebForms Core

Elanat Framework — Tue, 22 Sep 2026 18:23:01 +0000

TypeScript can be used with WebForms Core as an isomorphic WebForms Commander. This means the same WebForms class can be executed on both the server and client side.

Instead of directly manipulating the DOM, the WebForms class creates WebForms Core commands. These commands are then executed by WebFormsJS in the browser.

Installation via npm

The TypeScript WebForms class is available through npm.

npm install webformscore-ts

The package provides the TypeScript WebForms Commander for WebForms Core.

Commander and Executor

webforms.ts is an isomorphic class that can be executed on both the server and client side.

This is the Commander class and should not be confused with the client-only WebFormsJS Executor library.

WebForms Core consists of two main parts:

Commander: WebForms classes available for different programming languages.
Executor: WebFormsJS, a front-end library whose physical file is web-forms.js.

The Commander creates WebForms Core commands, while the Executor executes those commands in the browser.

WebFormsJS is normally placed in the <head> section of the HTML page. Other than its initial configuration, you work with the WebForms class functions rather than directly with WebFormsJS.

This separation allows the same command-based programming model to be used in different environments.

How to Work with WebForms Core in Front-End

The TypeScript WebForms class can also be used directly on the front-end.

Unlike WebForms classes that are primarily used on the server or WebAssembly, the TypeScript WebForms class is isomorphic and can run in both front-end and server-side environments. Since the TypeScript class is isomorphic, it can execute in a browser environment as well.

To use it on the front-end, first make the WebForms class available in your project. Then create a simple HTML page.

<!DOCTYPE html>
<html>
<head>
  <title>Using WebForms Core</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
    <button id="Button1">Set Dynamic Random Color</button>
    <script>
        window.addEventListener("load", (event) => {
            FrontBack(event, "/script/module/main.ts");
        });
    </script>
</body>
</html>

Usually, when the initial page is controlled from the server, the server can return HTML together with the output of the exportToHtmlComment() method. WebFormsJS automatically finds the Action Controls in the HTML comments and executes them.

In this example, however, the page is static. Therefore, the FrontBack method is assigned directly to the page load event.

After the page loads, FrontBack executes the specified module.

Modules executed through FrontBack must provide a PageLoad function with an evt argument.

Additional arguments can also be passed to FrontBack. When provided, they are added after the evt argument when PageLoad is called.

TypeScript Module

The following is /script/module/main.ts:

import { WebForms, HtmlEvent, Fetch } from "./webforms.ts";

export function PageLoad(evt)
{
    const form = new WebForms();

    form.setCommentEvent("Button1", HtmlEvent.OnClick, "random-color");

    form.startIndex("random-color");
    form.removeCommentEvent("Button1", HtmlEvent.OnClick);

    form.repeat((f) => {
        f.addSaveValue("color", "rgb({{R}}, {{G}}, {{B}})");
        f.replaceSaveValue("color", "{{R}}", Fetch.random(256));
        f.replaceSaveValue("color", "{{G}}", Fetch.random(256));
        f.replaceSaveValue("color", "{{B}}", Fetch.random(256));
        f.setBackgroundColor("<body>", Fetch.save("color"));
        f.delay(500);
    }, 31536000);

    return form.response();
}

Here, the WebForms class first assigns an event to Button1. When the button is clicked, the random-color command sequence starts.

The sequence generates three random values for red, green, and blue, creates an RGB color, and changes the page background. The repeat operation runs the sequence repeatedly with a 500 millisecond delay.

When the user clicks the button, the background color therefore changes to a new random RGB color every 500 milliseconds.

The important point is that the TypeScript Commander does not directly perform the DOM operation. It creates WebForms Core commands, and WebFormsJS executes those commands in the browser.

Using TypeScript with Node.js and Express

The same TypeScript WebForms class can be used on the server.

The following example uses Node.js and Express to process an HTML form and return WebForms Core commands.

import express from 'express';
import bodyParser from 'body-parser';
import { WebForms, InputPlace } from './webforms';

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

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

app.use(bodyParser.urlencoded({ extended: true }));

app.get('/', (req, res) => {
    res.send(`
        <!DOCTYPE html>
        <html>
        <head>
          <title>Using WebForms Core</title>
          <script type="module" src="/script/web-forms.js"></script>
        </head>
        <body>
            <form method="post" action="/">
                <label for="txt_Name">Your Name</label>
                <input name="txt_Name" id="txt_Name" type="text" />
                <br>
                <label for="txt_FontSize">Set Font Size</label>
                <input name="txt_FontSize" id="txt_FontSize" type="number" value="16" min="10" max="36" />
                <br>
                <label for="txt_BackgroundColor">Set Background Color</label>
                <input name="txt_BackgroundColor" id="txt_BackgroundColor" type="text" />
                <br>
                <input name="btn_SetBodyValue" type="submit" value="Click to send data" />
            </form>
        </body>
        </html>
    `);
});

app.post('/', (req, res) => {
    if (req.body.btn_SetBodyValue) {
        const name = req.body.txt_Name;
        const backgroundColor = req.body.txt_BackgroundColor;
        const fontSize = parseInt(req.body.txt_FontSize, 10);

        const form = new WebForms();

        form.setFontSize(InputPlace.tag('form'), fontSize);
        form.setBackgroundColor(InputPlace.tag('form'), backgroundColor);
        form.setDisabled(InputPlace.name('btn_SetBodyValue'), true);

        form.addTag(InputPlace.tag('form'), 'h3');
        form.setText(InputPlace.tag('h3'), `Welcome ${name}!`);

        res.send(form.response());
    }
});

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

In this example, Express receives the submitted form values. The TypeScript WebForms class then creates commands that modify the existing page.

The server can change the font size, change the background color, disable the submit button, add an h3 element, and set its text.

The response is generated with:

form.response();

The browser receives the WebForms Core commands and WebFormsJS executes them.

One Commander, Multiple Environments

TypeScript makes it possible to use the WebForms Core Commander in both browser and server environments.

The same programming model can therefore be used for:

Front-end TypeScript modules
Node.js applications
Express applications
Server-side HTML responses
Other JavaScript-compatible environments

The architecture remains simple:

TypeScript WebForms Class
          ↓
   WebForms Core Commands
          ↓
       WebFormsJS
          ↓
      HTML DOM

The TypeScript class decides what should happen, while WebFormsJS performs the execution in the browser.

WebFormsJS

As shown in the examples, WebFormsJS is included in the HTML <head>:

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

The WebFormsJS library is the Executor layer of WebForms Core. Application logic can remain focused on the WebForms class rather than directly manipulating the DOM.

The latest WebFormsJS script is available in the WebForms repository.

Conclusion

With the TypeScript WebForms class, WebForms Core can be used from both sides of a web application.

The Commander can run in TypeScript on the server or in the browser, while WebFormsJS provides the client-side execution layer.

This makes TypeScript a natural environment for building WebForms Core applications with the same command-based programming model across front-end and back-end development.

AssemblyScript WebAssembly Meets WebForms Core 2.1

Elanat Framework — Mon, 21 Sep 2026 21:17:18 +0000

What is WebForms Core?

WebForms Core is a server-orchestrated UI technology that allows the server to generate commands for manipulating the browser DOM and controlling UI behavior.

Its architecture can be summarized as:

Server → WebForms → Commands → WebFormsJS → HTML DOM

WebForms Core does not require a separate frontend project, component framework, JSX, or a virtual DOM. It works with standard HTML and lets the server define UI operations through the WebForms class.

With WebAssembly support, this architecture can also invoke WebAssembly methods as part of the UI execution flow.

This means WebAssembly does not have to replace the UI architecture. It can become an execution layer inside the UI architecture.

AssemblyScript WebAssembly

AssemblyScript is a TypeScript-like language designed to compile to WebAssembly.

This makes it particularly interesting for browser applications that want a WebAssembly execution layer while using a language syntax familiar to JavaScript and TypeScript developers.

In this example, AssemblyScript is used together with WebForms Core 2.1.

The AssemblyScript module can:

execute numerical methods
receive string parameters
create WebForms commands
return WebForms responses
generate HTML
participate in WebForms Core events

The important part is that the AssemblyScript code does not need to manipulate the browser DOM directly.

Instead, it can use the WebForms class to generate the WebForms Core response.

Installation via Package

AssemblyScript in npm

You can install the WebForms Core AssemblyScript package directly from npm:

webformscore-wasm

npm install webformscore-wasm

The package provides the AssemblyScript implementation required to use the WebForms Core API from AssemblyScript WebAssembly modules.

WebFormsJS in GitHub

Always get the latest version of WebFormsJS directly from GitHub:

WebFormsJS

WebFormsJS provides the client-side runtime responsible for executing WebForms Core commands in the browser.

Creating the AssemblyScript Project

An AssemblyScript project can be created using the AssemblyScript toolchain.

A typical project contains an entry point such as:

assembly/
    index.ts
    webforms.ts

The webforms.ts file contains the AssemblyScript implementation of the WebForms class.

The application can then compile the AssemblyScript source into a WebAssembly module.

For example, the resulting file can be:

release.wasm

Depending on the execution model, a JavaScript module can also be generated:

release.js

WebForms Core can work with the corresponding WebAssembly execution path.

Using WebForms Core from AssemblyScript

The interesting part of this example is that the AssemblyScript code uses the WebForms Core API directly.

The index.ts file contains the exported WebAssembly methods:

import { WebForms } from "./webforms";

export function add(a: i32, b: i32): i32 {
    return a + b;
}

export function setData(
    inputPlace: string,
    text: string,
    backgroundColor: string,
    fontSize: string
): string {
    const form = new WebForms();

    form.setText(inputPlace, text);
    form.setBackgroundColor("-", backgroundColor);
    form.setFontSize("-", fontSize);

    return form.response();
}

export function getHtml(): string {
    return "<marquee>Tag From Wasm!</marquee>";
}

export function createWebForms(): WebForms {
    return new WebForms();
}

There are three methods used by the WebForms Core example:

`add`

add(10000, 3)

returns:

`setData`

The method receives four strings:

inputPlace
text
backgroundColor
fontSize

It creates a WebForms object and generates a WebForms Core response.

`getHtml`

This method returns HTML:

<marquee>Tag From Wasm!</marquee>

The HTML can then be placed into the browser through a WebForms Core event.

The WebForms Class in AssemblyScript

The important architectural detail is that WebForms is not a browser component.

The AssemblyScript code uses it as a command generator.

For example:

const form = new WebForms();

form.setText(inputPlace, text);
form.setBackgroundColor("-", backgroundColor);
form.setFontSize("-", fontSize);

return form.response();

The resulting response is interpreted by WebFormsJS in the browser.

Therefore the flow becomes:

AssemblyScript
      ↓
WebForms
      ↓
WebForms Core Commands
      ↓
WebFormsJS
      ↓
HTML DOM

AssemblyScript does not need to know how the browser applies these commands.

That responsibility belongs to WebFormsJS.

Using AssemblyScript WebAssembly from WebForms Core

The server-side controller can invoke AssemblyScript methods through the WebForms Core WASM API.

The actual execution of the method takes place in the browser.

Server-side configuration
           ↓
      WebFormsJS
           ↓
Browser WebAssembly runtime
           ↓
  AssemblyScript method

The controller is:

using CodeBehind;

public partial class WasmAssemblyScriptController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        string WasmPath = "/web-assembly/assembly-script/release.wasm"; // or release.js

        WebForms form = new WebForms();

        form.AddText(
            "<b>",
            Fetch.WasmMethod(
                WasmLanguage.AssemblyScript,
                WasmPath,
                "add",
                [10000, 3]
            )
        );

        form.SetWasmEvent(
            "WasmEvent",
            HtmlEvent.OnClick,
            WasmLanguage.AssemblyScript,
            WasmPath,
            "setData",
            ["h3Tag", "Text From Wasm", "lightgreen", "30px"]
        );

        form.SetWasmEvent(
            "WasmEventWithOutput",
            HtmlEvent.OnClick,
            WasmLanguage.AssemblyScript,
            WasmPath,
            "getHtml",
            [],
            "WasmHtmlOutput"
        );

        Write(form.ExportToHtmlComment());
    }
}

The controller does not contain AssemblyScript implementation details.

It only defines how the WebAssembly methods participate in the WebForms Core UI flow.

HTML

The page itself remains ordinary HTML:

@page
@controller WasmAssemblyScriptController
@layout "/layout.aspx"
@{
  ViewData.Add("title","AssemblyScript Wasm");
}
<h3>AssemblyScript Wasm</h3>
<b>AssemblyScript WASM Result: </b>
<br>
<button id="WasmEvent">Wasm Event</button>
<br>
<h3 id="h3Tag">Wasm Tag Changing!</h3>
<button id="WasmEventWithOutput">Wasm Event With Output</button>
<p id="WasmHtmlOutput">Wasm Html Output</p>

There is no AssemblyScript-specific markup.

There is no custom WebAssembly element.

There is no component declaration.

The HTML remains standard HTML.

The Interesting Part

The controller uses the same WebForms Core concepts regardless of where the method is implemented.

For example:

form.AddText(
    "<b>",
    Fetch.WasmMethod(
        WasmLanguage.AssemblyScript,
        WasmPath,
        "add",
        [10000, 3]
    )
);

The add method is implemented in AssemblyScript, but its result can be consumed by WebForms Core.

The second method is more interesting:

form.SetWasmEvent(
    "WasmEvent",
    HtmlEvent.OnClick,
    WasmLanguage.AssemblyScript,
    WasmPath,
    "setData",
    ["h3Tag", "Text From Wasm", "lightgreen", "30px"]
);

When the button is clicked, WebFormsJS can invoke the AssemblyScript WebAssembly method.

The method creates a WebForms response:

const form = new WebForms();

form.setText(inputPlace, text);
form.setBackgroundColor("-", backgroundColor);
form.setFontSize("-", fontSize);

return form.response();

The response is then interpreted by WebFormsJS.

So the execution chain is:

HTML Event
    ↓
WebFormsJS
    ↓
AssemblyScript WASM
    ↓
WebForms
    ↓
WebForms Core Response
    ↓
WebFormsJS
    ↓
DOM

This is different from simply calling a WebAssembly function and returning a number.

The WebAssembly method can become a producer of UI commands.

WASM Event With Output

The third method demonstrates another possibility:

form.SetWasmEvent(
    "WasmEventWithOutput",
    HtmlEvent.OnClick,
    WasmLanguage.AssemblyScript,
    WasmPath,
    "getHtml",
    [],
    "WasmHtmlOutput"
);

The AssemblyScript method returns HTML:

export function getHtml(): string {
    return "<marquee>Tag From Wasm!</marquee>";
}

WebForms Core can then place the returned value into:

<p id="WasmHtmlOutput">Wasm Html Output</p>

This demonstrates that WebAssembly methods can participate directly in the WebForms Core output flow.

AssemblyScript Is an Execution Layer

This example demonstrates an important distinction.

WebAssembly is not being used here to build a complete frontend application.

AssemblyScript is being used as an execution layer.

The UI architecture remains:

HTML
  +
WebForms Core
  +
WebFormsJS

AssemblyScript is inserted where a WebAssembly execution capability is useful:

             WebForms Core
                  │
        ┌─────────┴─────────┐
        │                   │
   Server WebForms     WebAssembly
                            │
                      AssemblyScript

This allows the application to use WebAssembly selectively instead of moving the entire application into a WebAssembly frontend.

No JavaScript Business Logic

One of the interesting aspects of this architecture is that the application does not need custom JavaScript business logic for these operations.

The AssemblyScript method performs the computation or generates the WebForms Core response.

WebFormsJS remains the browser runtime responsible for executing the resulting commands.

Therefore:

AssemblyScript → WebForms Commands → WebFormsJS → DOM

rather than:

AssemblyScript → Custom JavaScript → DOM

This separation keeps the WebAssembly layer independent from the application's browser-side DOM implementation.

Standard HTML Remains the UI

The AssemblyScript example does not introduce a new component model.

The page still contains:

<h3 id="h3Tag">Wasm Tag Changing!</h3>

and:

<button id="WasmEvent">Wasm Event</button>

The server assigns behavior to these existing elements.

This is one of the important characteristics of WebForms Core.

WebAssembly does not require the UI to be redesigned around WebAssembly components.

AssemblyScript and WebForms Core

The AssemblyScript implementation demonstrates that a WebAssembly language can use the same WebForms Core model as other supported languages.

The important relationship is:

AssemblyScript
      ↓
WebForms Class
      ↓
Action Controls / Response
      ↓
WebFormsJS
      ↓
Browser DOM

The WebForms class acts as the bridge between application logic and WebForms Core command generation.

This makes the WebAssembly module more than an isolated computational library.

It can participate in the UI execution model.

WebAssembly Does Not Have to Replace the UI Architecture

A common approach to WebAssembly applications is to move a large portion of the frontend into the WebAssembly runtime.

WebForms Core takes a different approach.

WebAssembly can be introduced only where it provides value.

For example, an application can continue using:

standard HTML
server-side WebForms
WebFormsJS
server-generated commands

while selectively executing AssemblyScript code through WebAssembly.

This makes WebAssembly an execution capability rather than a mandatory application architecture.

AssemblyScript WebAssembly vs JavaScript

AssemblyScript provides a particularly interesting option for developers coming from the JavaScript and TypeScript ecosystem.

The source syntax is familiar:

export function add(a: i32, b: i32): i32 {
    return a + b;
}

but the resulting code executes as WebAssembly.

When combined with WebForms Core, the result is:

Server
  ↓
WebForms
  ↓
WebAssembly Method
  ↓
AssemblyScript
  ↓
WebForms Response
  ↓
WebFormsJS
  ↓
DOM

The browser therefore remains responsible for UI execution while AssemblyScript provides a WebAssembly execution layer.

WebForms Core 2.1

WebForms Core 2.1 extends the architecture beyond a single programming language.

The same general WebForms model can be used with different WebAssembly implementations.

This makes the WebAssembly layer replaceable.

An application can choose AssemblyScript when its execution model is appropriate, while other parts of the system can use different WebAssembly languages.

The UI command architecture does not have to change.

Final Result

The final application combines four technologies:

CodeBehind
     ↓
WebForms Core 2.1
     ↓
AssemblyScript WebAssembly
     ↓
WebFormsJS

AssemblyScript provides the WebAssembly execution layer.

WebForms provides the command-generation model.

WebFormsJS provides browser-side execution.

HTML remains the UI.

The result is a WebAssembly application model without requiring a separate frontend architecture.

Conclusion

AssemblyScript and WebForms Core provide an interesting combination.

AssemblyScript can be used to execute WebAssembly code while the WebForms class provides a direct way to generate WebForms Core responses.

The important point is not simply that AssemblyScript can run in the browser.

The more interesting idea is that WebAssembly can become another execution layer inside a server-orchestrated UI architecture.

Instead of replacing the HTML and UI architecture with a WebAssembly application, AssemblyScript can work inside the existing flow:

Server → WebForms → WebAssembly → WebForms Commands → WebFormsJS → DOM

This keeps the UI based on standard HTML while allowing WebAssembly to perform computation, generate UI responses, and participate in interactive browser events.

Experience the Server Renaissance in Julia: Build Interactive Web Pages with WebForms Core

Elanat Framework — Mon, 21 Sep 2026 20:51:24 +0000

Julia is widely known for numerical computing, scientific programming, data analysis, and high-performance applications. But Julia can also be used to build web applications.

With WebForms Core, Julia applications can manipulate the browser UI from the server using server-side WebForms classes and WebForms commands.

The result is a different approach to interactive web development:

Julia Server → WebForms → Commands → WebFormsJS → HTML DOM

Instead of writing JavaScript for every UI operation, the server can generate commands that WebFormsJS executes in the browser.

Installation and Downloads

The Julia implementation of WebForms Core is provided as WebForms.jl, while the browser-side Executor is provided by WebFormsJS.

Download WebForms.jl

Download the Julia WebForms Core library directly from GitHub:

Download WebForms.jl

Then include the library in your Julia application:

include("WebForms.jl")

import .WebFormsCore
import .WebFormsCore: WebForms
import .WebFormsCore.InputPlace

Download WebFormsJS

WebFormsJS is the client-side JavaScript Executor responsible for executing WebForms commands and manipulating the HTML DOM.

Get WebFormsJS in npm

WebFormsJS Page in Elanat

You can also obtain the source directly from GitHub:

WebFormsJS on GitHub

Note: We also attempted to publish the WebForms Core package for Julia through the Julia General registry. However, the registry has strict requirements for package structure, documentation, testing, versioning, and release management, and we did not have the time required to meet all of these requirements for this project. For this reason, we decided not to continue with the registration process. WebForms.jl will remain available directly from its GitHub repository, where Julia developers can download and use it.

In the examples in this article, web-forms.js is served by the Julia application through HTTP.jl:

if req.target == "/script/web-forms.js"
    js = read(
        joinpath(@__DIR__, "script", "web-forms.js"),
        String
    )

    return HTTP.Response(
        200,
        ["Content-Type" => "text/javascript"],
        js
    )
end

The web server used throughout the examples is HTTP.jl:

using HTTP

HTTP.serve(
    handle_request,
    "127.0.0.1",
    8080
)

This gives the application a simple architecture:

Julia + HTTP.jl
       │
       ▼
   WebForms.jl
       │
       ▼
 WebForms Commands
       │
       ▼
   WebFormsJS
       │
       ▼
    HTML DOM

WebForms Core for Julia

The Julia implementation of WebForms Core provides the WebForms API directly inside Julia applications.

A basic application can use Julia's HTTP package as its HTTP server:

using HTTP

include("WebForms.jl")

import .WebFormsCore
import .WebFormsCore: WebForms
import .WebFormsCore.InputPlace

The WebForms module provides the server-side API for creating and manipulating WebForms commands.

For example:

form = WebForms.Form()

WebForms.set_font_size(form, InputPlace.tag("form"), font_size)
WebForms.set_background_color(form, InputPlace.tag("form"), background_color)
WebForms.set_disabled(form, InputPlace.name("btn_SetBodyValue"), true)

WebForms.add_tag(form, InputPlace.tag("form"), "h3")
WebForms.set_text(form, InputPlace.tag("h3"), "Welcome $(name)!")

These operations do not directly manipulate the browser DOM from Julia.

Instead, they construct WebForms commands.

WebFormsJS then receives those commands and executes them in the browser.

A Complete Julia Example

Consider a simple page where the user enters a name, chooses a font size, and specifies a background color.

The HTML itself remains ordinary HTML:

html = """
<!DOCTYPE html>
<html>
<head>
  <title>Using WebForms Core</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
    <form method="post" action="/">
        <label for="txt_Name">Your Name</label>
        <input name="txt_Name" id="txt_Name" type="text" />
        <br>
        <label for="txt_FontSize">Set Font Size</label>
        <input name="txt_FontSize" id="txt_FontSize" type="number" value="16" min="10" max="36" />
        <br>
        <label for="txt_BackgroundColor">Set Background Color</label>
        <input name="txt_BackgroundColor" id="txt_BackgroundColor" type="text" />
        <br>
        <input name="btn_SetBodyValue" type="submit" value="Click to send data" />
    </form>
</body>
</html>
"""

When the form is submitted, Julia receives the request and processes the values:

body = String(req.body)
params = HTTP.queryparams(body)

if haskey(params, "btn_SetBodyValue")
    name = get(params, "txt_Name", "")
    background_color = get(params, "txt_BackgroundColor", "")
    font_size = parse(Int, get(params, "txt_FontSize", "16"))

    form = WebForms.Form()

    WebForms.set_font_size(
        form,
        InputPlace.tag("form"),
        font_size
    )

    WebForms.set_background_color(
        form,
        InputPlace.tag("form"),
        background_color
    )

    WebForms.set_disabled(
        form,
        InputPlace.name("btn_SetBodyValue"),
        true
    )

    WebForms.add_tag(
        form,
        InputPlace.tag("form"),
        "h3"
    )

    WebForms.set_text(
        form,
        InputPlace.tag("h3"),
        "Welcome $(name)!"
    )

    return HTTP.Response(
        200,
        WebForms.response(form)
    )
end

The important part is that the server does not need to return an entirely new HTML document.

It returns a WebForms response containing instructions for the browser.

The browser then executes those instructions through WebFormsJS.

Server-Orchestrated UI

This is the central idea behind WebForms Core.

The server determines what UI operation should happen, while WebFormsJS performs the actual browser-side execution.

For example:

Julia
  │
  │ WebForms commands
  ▼
WebForms
  │
  │ WebForms response
  ▼
WebFormsJS
  │
  │ DOM operations
  ▼
HTML DOM

This creates a Commander–Executor architecture.

The WebForms class acts as the server-side Commander.

WebFormsJS acts as the client-side Executor.

Julia therefore does not need to contain JavaScript implementations for every UI operation.

Interactive UI Without Writing JavaScript

WebForms Core can also define browser events from Julia.

Consider this page:

function html_form()
    return """
    <!DOCTYPE html>
    <html>
    <head>
        <title>WebForms Core Technology in Julia</title>
        <script type="module" src="/script/web-forms.js"></script>
    </head>
    <body>
        <h1>WebForms Core Technology in Julia</h1>
        <button id="Button1">Increase Textbox</button>
        <input type="number" id="Textbox1" value="40">
    </body>
    </html>
    """
end

The page contains an ordinary HTML button and input.

Now Julia can associate an event with that button:

form = WebForms.Form()

WebForms.set_comment_event(
    form,
    "Button1",
    HtmlEvent.OnClick,
    "incease"
)

The server can then define what should happen when the event occurs:

WebForms.start_index(form, "incease")

WebForms.increase_width(
    form,
    "Textbox1",
    Fetch.get_value("Textbox1")
)

The resulting WebForms instructions can be exported into HTML comments:

WebForms.export_to_html_comment(form)

The final response is:

return HTTP.Response(
    200,
    ["Content-Type" => "text/html; charset=utf-8"],
    html_form() *
    WebForms.export_to_html_comment(form)
)

WebFormsJS detects the WebForms instructions and executes them in the browser.

Fetching Browser Values

An important feature of this model is that commands can use values from the browser.

In the example:

Fetch.get_value("Textbox1")

represents the current value of the element.

That value can be used by another WebForms operation:

WebForms.increase_width(
    form,
    "Textbox1",
    Fetch.get_value("Textbox1")
)

This allows a sequence of server-defined UI operations to depend on browser state without requiring the Julia application to maintain a permanent mirror of the DOM.

HTML Remains HTML

One of the design goals of WebForms Core is to keep the HTML itself simple.

The page can remain:

<button id="Button1">Incease Textbox</button>
<input type="number" id="Textbox1" value="40">

There is no requirement to replace HTML with a component syntax.

The WebForms instructions can instead be transmitted separately or embedded as HTML comments.

This makes WebForms Core HTML-native.

Julia as the Server-Side UI Commander

The Julia application remains responsible for the server-side logic.

For example:

function handle_request(req::HTTP.Request)
    try
        if req.target == "/"
            form = WebForms.Form()

            WebForms.set_comment_event(
                form,
                "Button1",
                HtmlEvent.OnClick,
                "incease"
            )

            WebForms.start_index(form, "incease")

            WebForms.increase_width(
                form,
                "Textbox1",
                Fetch.get_value("Textbox1")
            )

            return HTTP.Response(
                200,
                ["Content-Type" => "text/html; charset=utf-8"],
                html_form() *
                WebForms.export_to_html_comment(form)
            )
        end

        return HTTP.Response(
            404,
            ["Content-Type" => "text/plain"],
            "Not Found"
        )

    catch e
        println("\n========== ERROR ==========")
        showerror(stdout, e, catch_backtrace())
        println("\n============================")
        println("REQUEST: ", req)

        return HTTP.Response(
            500,
            "Internal Server Error"
        )
    end
end

And the application can be started directly with:

HTTP.serve(
    handle_request,
    "127.0.0.1",
    8080
)

There is no separate frontend application required for this example.

WebForms Core and WebFormsJS

The Julia library is the server-side part of the technology.

The browser-side execution is performed by web-forms.js.

A Julia application can simply serve the JavaScript file:

if req.target == "/script/web-forms.js"
    js = read(
        joinpath(@__DIR__, "script", "web-forms.js"),
        String
    )

    return HTTP.Response(
        200,
        ["Content-Type" => "text/javascript"],
        js
    )
end

This separation is intentional.

The server-side WebForms implementation can be written in Julia, while the same WebFormsJS Executor can execute commands generated by WebForms implementations in different programming languages.

A Cross-Language Architecture

This makes WebForms Core different from a framework that couples a particular frontend runtime to a particular backend language.

The architecture is based on a protocol and an Executor:

Julia
C#
PHP
Python
R
Ruby
Go
JavaScript
Rust
Java
Elixir
Perl
Dart
C
C++
...
 │
 ▼
WebForms
 │
 ▼
WebForms Commands
 │
 ▼
WebFormsJS
 │
 ▼
HTML DOM

The server-side implementation can therefore be native to the programming language.

The browser does not need to know which programming language generated the commands.

Why Julia?

Julia already provides a powerful ecosystem for scientific and technical computing.

With WebForms Core, the same language can also participate in server-side interactive web applications while retaining its existing HTTP ecosystem.

A Julia application can therefore combine:

Julia application logic
HTTP.jl
WebForms Core
WebFormsJS
standard HTML

without requiring a separate JavaScript application to implement every interactive operation.

Stateless Server-Orchestrated UI

WebForms Core is designed around server-side commands rather than maintaining a server-side copy of the browser DOM.

The server receives a request, executes its logic, and generates commands.

The browser executes those commands.

Conceptually:

HTTP Request
     │
     ▼
Julia Server
     │
     ▼
WebForms Commands
     │
     ▼
HTTP Response
     │
     ▼
WebFormsJS
     │
     ▼
Browser DOM

The server does not need to maintain a persistent component tree representing the browser.

This makes the approach suitable for applications that prefer stateless HTTP request processing.

WebForms Core in Julia

The Julia implementation demonstrates that WebForms Core is not tied to a single programming language.

A Julia developer can write:

form = WebForms.Form()

WebForms.set_font_size(
    form,
    InputPlace.tag("form"),
    20
)

WebForms.set_background_color(
    form,
    InputPlace.tag("form"),
    "lightblue"
)

WebForms.set_text(
    form,
    InputPlace.tag("h3"),
    "Welcome Julia!"
)

and let WebFormsJS translate those server-generated commands into browser-side DOM operations.

That is the fundamental idea of Server-Orchestrated UI:

The server decides what should happen. The client executes it.

With WebForms Core, Julia can participate in that architecture while keeping the application logic on the server and the browser interface based on ordinary HTML and WebFormsJS.

I Built a Web Page with C! Here’s How WebForms Core Makes It Possible

Elanat Framework — Mon, 21 Sep 2026 17:26:54 +0000

C is one of the most influential programming languages in software development. It is widely used for operating systems, embedded systems, networking, infrastructure, and performance-critical software.

But can C also be used to build an interactive web application where the server controls the HTML interface?

Yes. And the server can control the HTML interface without requiring a separate frontend application.

WebForms Core (WFC) is a server-side UI manipulation technology developed by Elanat. It allows a server application to generate commands that manipulate the HTML DOM in the browser.

The basic architecture is:

C Server
    ↓
WebForms header
    ↓
Commands
    ↓
WebFormsJS
    ↓
HTML DOM

This article shows how to build a web application in C using Mongoose as the HTTP server and WebForms Core for server-side UI manipulation.

WebForms Core in C

The C implementation is provided as a single header file, WebForms.h.

This makes integration straightforward. The application does not need a specific C package manager for WebForms Core.

For the HTTP server, this example uses Mongoose:

#include "mongoose.h"
#include "WebForms.h"

Mongoose handles HTTP requests and responses, while WebForms Core generates commands for manipulating the browser interface.

The resulting stack is:

C Application
    │
    ├── Mongoose
    │      └── HTTP Server
    │
    └── WebForms Core
           └── UI Commands
                  ↓
              WebFormsJS
                  ↓
              HTML DOM

Download the mongoose.h and mongoose.c files directly from the link below:

https://github.com/cesanta/mongoose

The C WebForms header is available in the WebForms Core GitHub repository:

https://github.com/webforms-core/Web_forms_classes/tree/elanat_framework/c

You can get WebForms.h directly from the c directory and place it in your C project.

This makes the WebForms Core C implementation easy to integrate into projects using different build systems or development environments.

Building the Web Page in C

The HTML page can simply be stored as a C string:

static const char *view_html =
"<!DOCTYPE html>\n"
"<html>\n"
"<head>\n"
"  <title>Using WebForms Core</title>\n"
"  <script type=\"module\" src=\"/script/web-forms.js\"></script>\n"
"</head>\n"
"<body>\n"
"    <form method=\"post\" action=\"/\">\n"
"        <label for=\"txt_Name\">Your Name</label>\n"
"        <input name=\"txt_Name\" id=\"txt_Name\" type=\"text\" />\n"
"        <br>\n"
"        <label for=\"txt_FontSize\">Set Font Size</label>\n"
"        <input name=\"txt_FontSize\" id=\"txt_FontSize\" type=\"number\" />\n"
"        <br>\n"
"        <label for=\"txt_BackgroundColor\">Set Background Color</label>\n"
"        <input name=\"txt_BackgroundColor\" id=\"txt_BackgroundColor\" type=\"text\" />\n"
"        <br>\n"
"        <input name=\"btn_SetBodyValue\" type=\"submit\" value=\"Click to send data\" />\n"
"    </form>\n"
"</body>\n"
"</html>";

There is no JSX, no frontend component framework, and no separate frontend application.

The page is standard HTML.

Controlling the HTML from C

When the form is submitted, Mongoose provides the POST data:

char fontSize_str[32] = {0};
char background_color[128] = {0};
char name[128] = {0};

mg_http_get_var(
    &hm->body,
    "txt_FontSize",
    fontSize_str,
    sizeof(fontSize_str)
);

mg_http_get_var(
    &hm->body,
    "txt_BackgroundColor",
    background_color,
    sizeof(background_color)
);

mg_http_get_var(
    &hm->body,
    "txt_Name",
    name,
    sizeof(name)
);

A WebForms instance can then be created:

WebForms *form = webforms_create();

The server creates InputPlace selectors:

char *ipForm = webforms_ip_tag("form");
char *ipH3   = webforms_ip_tag("h3");
char *ipBtn  = webforms_ip_tag("btn_SetBodyValue");

And generates UI commands:

webforms_set_font_size(form, ipForm, fontSize);

webforms_set_background_color(
    form,
    ipForm,
    background_color
);

webforms_set_disabled(
    form,
    ipBtn,
    true
);

webforms_add_tag(
    form,
    ipForm,
    "h3",
    ""
);

webforms_set_text(
    form,
    ipH3,
    welcome
);

The C server is therefore not simply returning data. It is generating instructions for the browser.

Screenshot of page load

Screenshot after send data

Low-Overhead Server Commands

One of the interesting ideas behind WFC is that the server sends commands, rather than continuously sending a representation of the entire UI.

The commands are compact and can be embedded inside HTML comments:

Commands with html

...
<b> ... </b>
...
<div> ... </div>
...
<!--[web-forms]
st<h1>=WebForms Core in C!
bc<body>=lightblue-->

This has two useful properties.

First, the commands do not interfere with the visible HTML structure.

Second, the command representation has relatively low overhead because only the required UI operations need to be transmitted.

Commands without html

[web-forms]
fs<form>=26px
bc<form>=cadetblue
sd<btn_SetBodyValue>=1
nt<form>=h3
st<h3>=Welcome Adriano!

WebFormsJS detects the commands and executes them against the DOM.

Server
   ↓
Compact Commands
   ↓
WebFormsJS
   ↓
DOM Operations

A Different Approach to Stateless Server-Driven UI

Before WebForms Core, different systems and approaches attempted to combine server-side UI control with a stateless server and command-based communication.

This model has an obvious challenge:

How can multiple asynchronous interactions remain synchronized without requiring the server to maintain the complete client state?

WFC takes a different approach.

Several mechanisms work together to control the execution flow.

Queue Manager

Requests can be placed into a queue and processed serially.

Request 1
   ↓
Request 2
   ↓
Request 3

This helps preserve the order of UI operations.

Loader

When an operation depends on a server response, a Loader can temporarily lock the relevant interface before the result arrives.

This prevents the user from triggering conflicting interactions while the required server operation is still pending.

Serial Request Processing

Queued requests are processed in order, helping dependent UI operations execute in a predictable sequence.

DebounceDelay

For events that can fire repeatedly, DebounceDelay can prevent unnecessary requests from being generated too rapidly.

Together, these mechanisms address an important problem in interactive Server-Driven UI systems: synchronization between user actions, server responses, and client-side command execution.

Stateless by Design

WFC is, by itself, a stateless server-side UI architecture.

The server does not need to maintain a complete representation of the browser DOM.

A typical flow can therefore remain:

HTTP Request
     ↓
C Server
     ↓
WebForms Commands
     ↓
HTTP Response
     ↓
Browser

However, Stateless does not mean that server-side state is forbidden.

An application can still maintain state on the server when a particular page or scenario requires it.

The choice depends on the application's requirements.

Memory Management in C

Because this implementation is written in C, memory management is explicit.

For example:

WebForms *form = webforms_create();

creates a WebForms instance, while:

webforms_clean(form);
webforms_free(form);

cleans and releases it.

InputPlace values returned by:

webforms_ip_tag("form");

are heap-allocated strings and therefore must also be released:

free(ipForm);
free(ipH3);
free(ipBtn);

The response returned by:

char *response = webforms_response(form);

is also heap-allocated and must be released after sending it:

free(response);

This keeps the API compatible with the explicit memory-management model expected in C.

Running the C Web Server

Mongoose can listen for HTTP connections with:

mg_http_listen(
    &mgr,
    "http://127.0.0.1:8080",
    fn,
    NULL
);

The event loop is then kept alive with:

for (;;) {
    mg_mgr_poll(&mgr, 1000);
}

The application can be opened at:

http://127.0.0.1:8080/

WebFormsJS can also be served directly by Mongoose.

C as a Web Programming Language

The complete stack is surprisingly small:

C
+
Mongoose
+
WebForms Core
+
WebFormsJS
+
HTML

There is no requirement for React, JSX, a frontend build system, or a separate frontend application.

The C application handles the server logic.

WebForms Core generates UI commands.

WebFormsJS executes those commands.

The browser remains the final place where the HTML DOM is manipulated.

Conclusion

Building an interactive web application in C does not require turning C into a frontend language.

Instead, C can remain the server-side language while WebForms Core provides a command-based mechanism for controlling the browser UI.

The architecture is:

C Server
    ↓
WebForms
    ↓
Commands
    ↓
WebFormsJS
    ↓
HTML DOM

WFC combines this architecture with compact commands, HTML-comment command embedding, queue management, serial request processing, Loader controls, and event debouncing.

The result is a server-oriented, stateless-by-design approach to interactive web UI, while still allowing applications to keep server-side state when a specific scenario requires it.

And yes, this entire example starts with a language that was originally designed decades ago for systems programming:

Web Programming in C++ with WFC

Elanat Framework — Sun, 20 Sep 2026 18:37:20 +0000

C++ is one of the most powerful and widely used programming languages in the world. It is well known for high-performance software, system programming, networking, game engines, embedded systems, and infrastructure.

But can C++ also be used to build modern web applications with server-side control over the HTML user interface?

Yes.

WebForms Core (WFC) is a server-side UI manipulation technology created by Elanat. It allows a server application to generate commands that manipulate the HTML interface in the browser.

Instead of creating a completely separate frontend application, the server can define UI operations and behaviors, while WebFormsJS executes those commands in the browser.

The basic architecture is:

C++ Server
    ↓
WebForms Class
    ↓
Action Controls
    ↓
WebFormsJS
    ↓
HTML DOM

This article demonstrates how to use WebForms Core with C++ to build web applications, including a form-based application and an interactive video player.

WebForms Core in C++

For C and C++, there are several package management ecosystems and dependency management approaches. Because of the diversity of these systems, the WebForms Core C++ implementation is provided directly as a header file rather than requiring a specific C++ package manager.

The C++ WebForms class is available in the WebForms Core GitHub repository:

https://github.com/webforms-core/Web_forms_classes/tree/elanat_framework/cpp

The file required by the application is:

WebForms.h

You can get WebForms.h directly from the cpp directory and place it in your C++ project.

This makes the WebForms Core C++ implementation easy to integrate into projects using different build systems or development environments.

There is no requirement to use a particular C++ package manager for WebForms Core itself.

Using cpp-httplib

For the HTTP server in the examples, we use cpp-httplib, a C++ HTTP server/client library.

The httplib.h file used in these examples is obtained directly from the official GitHub repository:

https://github.com/yhirose/cpp-httplib

Just like WebForms.h, the header can be placed directly into the C++ project.

A simplified project structure can therefore look like this:

C++ Web Project/
├── main.cpp
├── WebForms.h
├── httplib.h
├── api/
│   ├── video.json
│   └── template.html
└── script/
    └── web-forms.js

The two headers have different responsibilities:

#include "httplib.h"
#include "WebForms.h"

cpp-httplib is used to create the HTTP server and handle HTTP requests and responses.

WebForms Core is used to create server-side UI commands.

The architecture is therefore:

C++ Application
       │
       ├── cpp-httplib
       │       │
       │       └── HTTP Server
       │
       └── WebForms Core
               │
               └── UI Commands
                       │
                       ▼
                   WebFormsJS
                       │
                       ▼
                    HTML DOM

This combination is not a dependency relationship between the two libraries. They simply work together in the application: cpp-httplib handles HTTP, while WebForms Core handles server-side UI manipulation.

Building a Web Server with C++

Let's start with a simple web application.

We include the standard C++ libraries together with httplib.h and WebForms.h:

#include <iostream>
#include <string>

#include "httplib.h"
#include "WebForms.h"

using namespace std;
using namespace WebFormsCore;

We can then define an HTML view:

string backEndRender(const string& viewName) {
    if (viewName == "view") {
        return R"(<!DOCTYPE html>
<html>
<head>
  <title>Using WebForms Core</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
    <form method="post" action="/">

        <label for="txt_Name">Your Name</label>
        <input name="txt_Name" id="txt_Name" type="text" />
        <br>

        <label for="txt_FontSize">Set Font Size</label>
        <input name="txt_FontSize"
               id="txt_FontSize"
               type="number"
               value="16"
               min="10"
               max="36" />
        <br>

        <label for="txt_BackgroundColor">
            Set Background Color
        </label>

        <input name="txt_BackgroundColor"
               id="txt_BackgroundColor"
               type="text" />
        <br>

        <input name="btn_SetBodyValue"
               type="submit"
               value="Click to send data" />

    </form>
</body>
</html>)";
    }

    return "<h1>View not found</h1>";
}

The HTML is standard HTML. There is no JSX, no frontend component framework, and no special frontend build system required.

Manipulating the UI from C++

Now the C++ server can handle the POST request:

svr.Post("/", [](const httplib::Request& req,
                 httplib::Response& res) {

    if (req.has_param("btn_SetBodyValue")) {

        int fontSize =
            std::stoi(req.get_param_value("txt_FontSize"));

        std::string backgroundColor =
            req.get_param_value("txt_BackgroundColor");

        std::string name =
            req.get_param_value("txt_Name");

        WebForms form;

        form.SetFontSize(
            InputPlace::Tag("form"),
            fontSize
        );

        form.SetBackgroundColor(
            InputPlace::Tag("form"),
            backgroundColor
        );

        form.SetDisabled(
            InputPlace::Tag("btn_SetBodyValue"),
            true
        );

        form.AddTag(
            InputPlace::Tag("form"),
            "h3"
        );

        form.SetText(
            InputPlace::Tag("h3"),
            "Welcome " + name + "!"
        );

        res.set_content(
            form.Response(),
            "text/plain"
        );
    }
    else {
        res.set_content(
            backEndRender("view"),
            "text/html"
        );
    }
});

The important point is that the C++ application is not simply returning data.

It is creating UI commands.

For example:

form.SetFontSize(
    InputPlace::Tag("form"),
    fontSize
);

creates a command that changes the font size of the target element.

Likewise:

form.SetBackgroundColor(
    InputPlace::Tag("form"),
    backgroundColor
);

changes the background color.

And:

form.SetDisabled(
    InputPlace::Tag("btn_SetBodyValue"),
    true
);

disables the submit button.

The server can also create new HTML elements:

form.AddTag(
    InputPlace::Tag("form"),
    "h3"
);

form.SetText(
    InputPlace::Tag("h3"),
    "Welcome " + name + "!"
);

The resulting commands are sent to the browser, where WebFormsJS executes them against the DOM.

Starting the C++ Server

The GET request returns the initial HTML page:

svr.Get("/", [](const httplib::Request&,
                httplib::Response& res) {

    res.set_content(
        backEndRender("view"),
        "text/html"
    );
});

The WebFormsJS file can be served using cpp-httplib:

svr.set_mount_point("/script", "./script");

Finally, the server listens on port 8080:

svr.listen("127.0.0.1", 8080);

The application can then be accessed at:

http://127.0.0.1:8080/

Building a Video Player with C++

WebForms Core is not limited to forms and simple DOM modifications.

It can also be used to build more interactive interfaces.

The second example is a video player that loads a list of videos from a JSON file and creates the video cards dynamically.

The JSON file contains:

[
  {
    "title": "Big Buck Bunny",
    "path": "https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/720/Big_Buck_Bunny_720_10s_1MB.mp4"
  },
  {
    "title": "Sintel",
    "path": "https://test-videos.co.uk/vids/sintel/mp4/h264/720/Sintel_720_10s_2MB.mp4"
  },
  {
    "title": "Flower",
    "path": "https://interactive-examples.mdn.mozilla.net/media/cc0-videos/flower.mp4"
  },
  {
    "title": "Elephants Dream",
    "path": "https://archive.org/download/ElephantsDream/ed_1024_512kb.mp4"
  }
]

The C++ application exposes the JSON file through an HTTP endpoint:

svr.Get("/api/video.json",
    [](const httplib::Request&,
       httplib::Response& res) {

    string content;

    if (!readFile("./api/video.json", content)) {
        res.status = 500;
        res.set_content(
            "Cannot read api/video.json",
            "text/plain"
        );
        return;
    }

    res.set_content(
        content,
        "application/json"
    );
});

The application also exposes the HTML template:

svr.Get("/api/template.html",
    [](const httplib::Request&,
       httplib::Response& res) {

    string content;

    if (!readFile("./api/template.html", content)) {
        res.status = 500;
        res.set_content(
            "Cannot read api/template.html",
            "text/plain"
        );
        return;
    }

    res.set_content(
        content,
        "text/html"
    );
});

The WebForms Video Interface

We start by creating a WebForms instance:

WebForms form;

The video data is loaded and stored using WebForms Core:

form.NotExist(
    Fetch::Cache("video-data")
);

form.AddCacheValue(
    "video-data",
    Fetch::LoadUrl("/api/video.json")
);

We can then iterate over the JSON data:

form.ForEach(
    "[0]",
    Fetch::Cache("video-data"),
    "foreach-data"
);

Inside the loop, the HTML template is loaded and populated:

form.StartBracket();

    form.AddText(
        "{video-container}",
        Fetch::LoadHtml(
            "/api/template.html",
            "Video"
        )
    );

    form.BindJSONToTemplate(
        "{video-card}-1",
        Fetch::FormatStore("foreach-data"),
        "[0]",
        "{{value}}"
    );

    form.SetCommentEvent(
        "{video-card}-1|<>",
        HtmlEvent::OnClick,
        "play-video"
    );

form.EndBracket();

The template is:

<!DOCTYPE html>

<template id="Video">
    <div class="video-card">
        <b data-path="{{path}}">
            {{title}}
        </b>
    </div>
</template>

The JSON data is therefore transformed into a collection of video cards.

Screenshot of Video Player

Playing the Selected Video

When the user clicks a video card, the play-video action is executed:

form.StartIndex("play-video");

form.SetAttribute(
    "video",
    HtmlEvent::OnLoadStart,
    "this.play()"
);

form.SetAttribute(
    "video",
    "src",
    Fetch::GetAttribute("$", "data-path")
);

form.SetText(
    "video-name",
    Fetch::GetText("$")
);

The selected video's data-path is used as the source of the HTML <video> element:

form.SetAttribute(
    "video",
    "src",
    Fetch::GetAttribute("$", "data-path")
);

The selected video's title is also displayed:

form.SetText(
    "video-name",
    Fetch::GetText("$")
);

This is an important characteristic of WebForms Core.

The server can define not only the data that should be displayed, but also the UI operations that should take place when the user interacts with the page.

The HTML Interface

The frontend remains standard HTML:

<main>
    <h1>Web Project in C++</h1>

    <h2>
        Building a Video Player with WebForms Core
    </h2>

    <div class="video-container"></div>

    <video id="video"
           controls
           playsinline></video>

    <div id="now-playing">
        <span class="playing-indicator">●</span>
        <span class="video-icon">🎬</span>
        <span id="video-name">
            No video selected
        </span>
    </div>
</main>

The WebForms commands are exported into HTML comments:

html += form.ExportToHtmlComment(true);

WebFormsJS detects these commands in the browser and executes them.

This means the server can send an HTML page together with the operations required to manipulate that page.

The Architecture

The complete architecture of the C++ example can be represented as:

                    C++ Application
                           │
             ┌─────────────┴─────────────┐
             │                           │
        cpp-httplib                WebForms Core
             │                           │
             │                    WebForms Class
             │                           │
             │                    Action Controls
             │                           │
             └──────────────┬────────────┘
                            │
                            ▼
                       HTTP Response
                            │
                            ▼
                         Browser
                            │
                            ▼
                       WebFormsJS
                            │
                            ▼
                        HTML DOM

cpp-httplib provides the HTTP server layer.

WebForms Core provides the server-side UI manipulation layer.

WebFormsJS acts as the browser-side executor.

The final target is the HTML DOM.

C++ as a Web Programming Language

C++ is not limited to desktop applications, game engines, or system software.

With an HTTP library such as cpp-httplib, C++ can be used to create web servers. With WebForms Core, the same C++ application can also orchestrate operations on the browser's HTML interface.

The resulting stack is simple:

C++
+
cpp-httplib
+
WebForms Core
+
WebFormsJS
+
HTML

There is no requirement to introduce a separate JavaScript frontend framework.

The application can keep its server-side logic in C++, while the browser receives HTML and WebForms commands.

Direct Header-Based Integration

One of the notable aspects of this C++ implementation is its direct integration model.

For WebForms Core:

WebForms.h

is obtained directly from the WebForms Core C++ source directory.

For the HTTP server:

httplib.h

is obtained directly from the cpp-httplib GitHub repository.

This gives the example a straightforward project structure without requiring a specific C++ package manager:

main.cpp
WebForms.h
httplib.h

Additional files such as HTML templates, JSON data, and web-forms.js can then be added according to the requirements of the application.

This approach can be useful for C++ projects where developers prefer direct header integration or where the project already has its own build and dependency management system.

Conclusion

Web programming in C++ is possible, and WebForms Core provides a way to bring server-side UI manipulation into C++ web applications.

In these examples, cpp-httplib provides the HTTP server while WebForms Core provides the UI command layer.

The server can:

Serve standard HTML.
Receive HTTP requests.
Process form data in C++.
Generate UI commands.
Manipulate HTML elements.
Load JSON data.
Bind JSON data to HTML templates.
Respond to user interactions.
Control an HTML video player.

The resulting architecture keeps the application server-oriented:

C++ Server
    ↓
WebForms
    ↓
Commands
    ↓
WebFormsJS
    ↓
HTML DOM

WebForms Core is developed and maintained by Elanat, and the C++ implementation is available directly through the WebForms Core GitHub repository.

The combination of C++, cpp-httplib, WebForms Core, WebFormsJS, and standard HTML provides another way to build interactive web applications without requiring a separate frontend framework.

New Server-Driven UI in Elixir: Stateless, RESTful, and HTML-Native with WFC

Elanat Framework — Sat, 19 Sep 2026 17:20:35 +0000

What if a web application could provide rich, interactive user interfaces while keeping the server stateless, using standard HTTP, working naturally with RESTful architectures, and remaining based on HTML?

What if the server could define UI behavior without maintaining a server-side representation of the browser DOM?

This is the approach introduced by WebForms Core (WFC).

WebForms Core is a server-side UI manipulation technology developed by Elanat. It allows server-side code to generate commands that describe operations on the HTML DOM. These commands are then executed by WebFormsJS, the browser runtime of WFC.

The basic architecture is:

Server
   ↓
WebForms
   ↓
Commands
   ↓
WebFormsJS
   ↓
HTML DOM

With Elixir and Phoenix, this becomes:

Phoenix Controller
        ↓
    WebForms
        ↓
    Commands
        ↓
   WebFormsJS
        ↓
    HTML DOM

The important point is that the server does not need to keep a copy of the browser's UI state.

The browser owns the DOM.

The server generates commands.

WebFormsJS executes them.

A Stateless Approach to Server-Driven UI

Many interactive web architectures introduce some form of persistent UI state on the server.

WFC takes a different approach.

The server can process a request, generate the required UI commands, return the response, and finish processing the request.

Conceptually:

Request
   ↓
Server
   ↓
Generate Commands
   ↓
Response
   ↓
Server Request State Ends

The server does not need to maintain a continuously synchronized representation of the client's DOM.

This makes the architecture naturally compatible with stateless HTTP applications and horizontal scaling.

For example, multiple server instances can process independent requests:

                 ┌── Server A
Browser ── HTTP ─┼── Server B
                 └── Server C

The application does not need a particular server instance to continuously own the browser's UI state.

HTML Is Still the Interface

WFC does not require a proprietary UI markup language.

The interface is HTML.

A normal Phoenix template can contain:

<form method="post" action="/">
    <label for="txt_Name">Your Name</label>
    <input name="txt_Name" id="txt_Name" type="text">

    <input name="btn_SetBodyValue"
           type="submit"
           value="Click to send data">
</form>

There is no requirement to convert the page into a separate component language.

The HTML remains the HTML that the browser understands.

WebFormsJS operates on that existing DOM.

This creates a simple relationship:

HTML
  +
WebFormsJS
  +
Server Commands
  =
Interactive UI

RESTful and HTTP-Friendly

A Server-Driven UI architecture does not necessarily require a persistent connection between the server and the browser.

WFC commands can be returned through ordinary HTTP responses.

For example:

POST /submit
        ↓
Phoenix Controller
        ↓
    WebForms
        ↓
WebForms Core Response
        ↓
  HTTP Response
        ↓
   WebFormsJS
        ↓
   DOM Update

This fits naturally into the request/response model of the web.

At the same time, WFC is not restricted to HTTP request/response communication.

Depending on the application's requirements, server-generated commands can also be transported through technologies such as:

HTTP
WebSocket
Server-Sent Events (SSE)

The command architecture remains the same.

Only the transport mechanism changes.

                  ┌── HTTP
WebForms Commands ├── WebSocket
                  └── SSE
                       ↓
                  WebFormsJS
                       ↓
                   HTML DOM

This separation between command generation and transport allows the UI architecture to remain independent from a single communication mechanism.

Server-Orchestrated UI

WFC can be described as a Server-Orchestrated UI architecture.

The server determines which UI operations should occur.

For example, server-side Elixir code can express:

form =
  WebForms.new()
  |> WebForms.set_font_size(InputPlace.tag("form"), 20)
  |> WebForms.set_background_color(InputPlace.tag("form"), "#eeeeee")
  |> WebForms.set_disabled(InputPlace.name("btn_SetBodyValue"), true)

The server is defining behavior.

The browser is executing behavior.

WebFormsJS receives the generated commands and applies them to the DOM.

The server does not need to send a complete replacement page.

It can send only the operations required for the current interaction.

The Commander–Executor Architecture

This creates a clear division between the server and the browser.

             SERVER
                │
                ▼
          WebForms Class
            Commander
                │
                ▼
       WebForms Commands
                │
                ▼
             BROWSER
                │
                ▼
           WebFormsJS
            Executor
                │
                ▼
            HTML DOM

The WebForms class is the Commander.

It creates the instructions.

WebFormsJS is the Executor.

It interprets and executes the instructions.

This is different from sending application-level JavaScript from the server.

The server generates WebForms Core commands, while WebFormsJS provides the runtime that understands those commands.

Building a Phoenix Application

Let's see how this architecture works in a real Elixir application.

The example uses Phoenix and the wfc package.

Add WFC to the project's dependencies:

defp deps do
  [
    {:wfc, "~> 2.1"}
  ]
end

Then fetch the dependency:

mix deps.get

The package provides the WebFormsCore namespace:

alias WebFormsCore.{WebForms, InputPlace}

The Phoenix View

Create an index.html.heex view:

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

<form method="post" action="/">
    <label for="txt_Name">Your Name</label>
    <input name="txt_Name" id="txt_Name" type="text">
    <br>

    <label for="txt_FontSize">Set Font Size</label>
    <input name="txt_FontSize"
           id="txt_FontSize"
           type="number"
           value="16"
           min="10"
           max="36">
    <br>

    <label for="txt_BackgroundColor">Set Background Color</label>
    <input name="txt_BackgroundColor"
           id="txt_BackgroundColor"
           type="text">
    <br>

    <input name="btn_SetBodyValue"
           type="submit"
           value="Click to send data">
</form>

The first GET / request renders the complete HTML page.

The browser now owns the interface.

When the user submits the form, Phoenix receives the form data.

The controller can then generate commands instead of rendering another complete page.

The Phoenix Controller

Create my_controller.ex:

defmodule MyAppWeb.MyController do
  use MyAppWeb, :controller

  alias WebFormsCore.{WebForms, InputPlace}

  def index(conn, _params) do
    render(conn, :index)
  end

  def submit(conn, %{
        "txt_Name" => name,
        "txt_BackgroundColor" => background_color,
        "txt_FontSize" => font_size,
        "btn_SetBodyValue" => _button
      }) do
    form =
      WebForms.new()
      |> WebForms.set_font_size(InputPlace.tag("form"), String.to_integer(font_size))
      |> WebForms.set_background_color(InputPlace.tag("form"), background_color)
      |> WebForms.set_disabled(InputPlace.name("btn_SetBodyValue"), true)
      |> WebForms.add_tag(InputPlace.tag("form"), "h3", nil)
      |> WebForms.set_text(InputPlace.tag("h3"), "Welcome #{name}!")

    text(conn, WebForms.response(form))
  end
end

The controller creates a WebForms object and builds the UI operations.

For example:

WebForms.set_font_size(
  InputPlace.tag("form"),
  String.to_integer(font_size)
)

changes the font size of the <form> element.

This:

WebForms.set_background_color(
  InputPlace.tag("form"),
  background_color
)

changes its background color.

And:

WebForms.set_disabled(
  InputPlace.name("btn_SetBodyValue"),
  true
)

disables the submit button.

The controller can also create new HTML elements:

WebForms.add_tag(
  InputPlace.tag("form"),
  "h3",
  nil
)

and set their contents:

WebForms.set_text(
  InputPlace.tag("h3"),
  "Welcome #{name}!"
)

Finally:

text(conn, WebForms.response(form))

returns the generated WebForms Core response.

The response contains the commands that WebFormsJS will execute.

Phoenix Router

Add the routes:

defmodule MyAppWeb.Router do
  use MyAppWeb, :router

  scope "/", MyAppWeb do
    get "/", MyController, :index
    post "/", MyController, :submit
  end
end

The request flow is now:

GET /
  ↓
Phoenix
  ↓
HTML View
  ↓
Browser

After submitting the form:

POST /
  ↓
Phoenix Controller
  ↓
WebForms
  ↓
WebForms Core Commands
  ↓
HTTP Response
  ↓
WebFormsJS
  ↓
HTML DOM

No server-side DOM needs to be maintained.

WebFormsJS

WebFormsJS is the browser runtime responsible for executing WebForms Core commands.

Load it with:

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

Its role is not to replace HTML.

Its role is to operate on HTML.

The relationship is:

Server
  ↓
Command
  ↓
WebFormsJS
  ↓
Existing HTML DOM

This makes WebFormsJS an execution layer rather than a replacement for the browser's native document model.

Get WebFormsJS in GitHub: https://github.com/webforms-core/Web_forms

Get WebFormsJS in Elanat: https://elanat.net/webforms-js

Designed for Scale

Statelessness is particularly important for large web applications.

When UI state does not need to remain attached to a particular server process, requests can be distributed across multiple application instances.

                         ┌── Phoenix Server 1
                         │
Browser ── Load Balancer ├── Phoenix Server 2
                         │
                         └── Phoenix Server 3

Each request can be processed independently.

The server receives the request, executes application logic, generates the required UI commands, returns the response, and completes the request.

This architecture can work naturally with common scaling mechanisms such as load balancing and multiple application instances.

The browser remains responsible for the DOM.

The server remains responsible for application logic and command generation.

Stateless Does Not Mean Less Interactive

A stateless server does not mean a static interface.

WFC commands can perform a wide range of DOM operations.

The server can instruct the browser to:

Change text
Change attributes
Change styles
Add elements
Remove elements
Enable or disable controls
Replace content
Move through UI flows
Respond to user interactions

The interaction can therefore remain dynamic while the server remains stateless.

This is an important distinction:

Stateless Server
        ≠
Static UI

A server can be stateless while still orchestrating rich browser interactions.

One UI Architecture, Multiple Transports

Another important property of WFC is the separation between what should happen and how the command is transported.

The UI command itself can remain conceptually the same:

Set Text
Set Style
Add Element
Disable Button
Replace Content

The transport can vary:

HTTP
WebSocket
SSE

This makes it possible to select a communication model based on application requirements without changing the fundamental UI command architecture.

For a conventional form submission, HTTP may be sufficient.

For continuous server-to-browser events, SSE may be appropriate.

For bidirectional real-time communication, WebSocket may be appropriate.

The WebFormsJS runtime remains the execution environment.

HTML-Native Server-Driven UI

The web platform already provides a powerful document model: HTML and the DOM.

WFC builds its UI architecture around that model.

There is no requirement for a separate virtual DOM.

There is no requirement for a separate frontend project.

There is no requirement for a client-side component build pipeline.

The fundamental UI remains:

HTML → DOM

WebForms Core adds a server-generated command layer:

Server
   ↓
Commands
   ↓
WebFormsJS
   ↓
HTML DOM

This keeps the browser interface close to the native web platform while allowing the server to orchestrate interactive behavior.

A Different Way to Build Interactive Web Applications

WebForms Core combines several architectural ideas:

Stateless Server
       +
RESTful / HTTP Architecture
       +
HTML-Native UI
       +
Server-Generated Commands
       +
Browser Runtime
       +
Multiple Transports
       ↓
Server-Orchestrated UI

For Elixir applications, Phoenix provides the server-side web framework, while WFC provides the server-side UI command layer and WebFormsJS provides the browser-side execution runtime.

The result is a model where:

The server owns the application logic.

The browser owns the DOM.

WebForms defines the UI commands.

WebFormsJS executes the commands.

And the server does not need to maintain a continuously synchronized copy of the browser interface.

Final Architecture

The complete architecture can be summarized in one diagram:

                         SERVER
                            │
                     Phoenix / Elixir
                            │
                            ▼
                      WebForms Class
                        Commander
                            │
                            ▼
                  WebForms Core Commands
                            │
                 ┌──────────┼──────────┐
                 │          │          │
                HTTP       SSE     WebSocket
                 │          │          │
                 └──────────┼──────────┘
                            │
                            ▼
                        WebFormsJS
                         Executor
                            │
                            ▼
                        HTML DOM

This is the core idea behind the new Server-Driven UI approach of WebForms Core:

The server orchestrates.

The browser executes.

HTML remains the interface.

The server remains stateless.

WebForms Core is a technology owned and developed by Elanat.

Official website: https://elanat.net

WebForms Core: https://elanat.net/webforms-core

WebForms Core GitHub: https://github.com/webforms-core

New Server-Driven UI in Dart - WebForms Core

Elanat Framework — Fri, 18 Sep 2026 19:41:58 +0000

What if you could build interactive web interfaces in Dart, without writing a separate JavaScript UI layer?

What if the server could define not only the initial HTML, but also the UI behavior that should happen when the user interacts with that HTML?

A new approach is now available for Dart.

WebForms Core (WFC) is now available for Dart.

WebForms Core is a server-side UI manipulation technology created by Elanat. It allows server-side code to generate commands for manipulating the browser DOM through the WebFormsJS runtime.

And now, Dart can act as a WebForms Commander.

A Different Approach to Web UI

A typical Dart web application can use Dart to build its server-side application and return HTML to the browser. Client-side JavaScript can then take responsibility for interactive behavior.

WebForms Core takes a different approach.

The server can define UI operations such as:

creating HTML elements
changing styles
changing attributes
changing text
responding to events
reading values from the DOM
executing conditional logic
controlling UI flow

The browser does not need to understand Dart.

Instead, the server generates WebForms Core commands, and WebFormsJS interprets and executes those commands in the browser.

The architecture is:

Dart
  ↓
WebForms
  ↓
Action Controls
  ↓
WebFormsJS
  ↓
HTML DOM

This is not a JavaScript framework.

It is a Commander–Executor architecture.

Dart is the Commander.

WebFormsJS is the Executor.

A First Dart Example

Let's start with something very simple.

Imagine a page containing a <select> element. The user selects a color, and the background and text color of the page change immediately.

Here is the Dart code:

import 'dart:io';
import 'package:shelf/shelf.dart';
import 'package:shelf/shelf_io.dart' as io;
import 'package:shelf_router/shelf_router.dart';

import 'package:webforms/webforms.dart';

void main() async {
  var router = Router();

  router.get('/script/web-forms.js', (Request request) {
    final file = File('web/script/web-forms.js');
    if (!file.existsSync()) {
      return Response.notFound('web-forms.js not found');
    }
    return Response.ok(
      file.readAsStringSync(),
      headers: {'Content-Type': 'application/javascript; charset=utf-8'},
    );
  });

  router.get('/', (Request request) {
    final form = WebForms();

    form.addOptionTag("<select>", "White", "white");
    form.addOptionTag("-", "Light Green", "lightgreen");
    form.addOptionTag("-", "Light Blue", "lightblue");
    form.addOptionTag("-", "Red", "red");
    form.addOptionTag("-", "Blue", "blue");
    form.addOptionTag("-", "Green", "green");
    form.addOptionTag("-", "Yellow", "yellow");
    form.addOptionTag("-", "Orange", "orange");
    form.addOptionTag("-", "Purple", "purple");
    form.addOptionTag("-", "Pink", "pink");
    form.addOptionTag("-", "Brown", "brown");
    form.addOptionTag("-", "Black", "black");
    form.addOptionTag("-", "Gray", "gray");

    form.setCommentEvent("-", HtmlEvent.onChange, index: "set-color");

    form.startIndex("set-color");
    form.setBackgroundColor("<body>", Fetch.getValue("<select>"));
    form.isEqualTo("black", Fetch.getValue("<select>"));
        form.setTextColor("<body>", "white");
    form.else_();
        form.setTextColor("<body>", "black");

    return Response.ok(
      _htmlForm() + form.exportToHtmlComment(),
      headers: {'Content-Type': 'text/html; charset=utf-8'},
    );
  });

  var server = await io.serve(
    router,
    InternetAddress.loopbackIPv4,
    8080,
  );

  print('Server running on http://${server.address.host}:${server.port}');
}

String _htmlForm() {
  return '''
<!DOCTYPE html>
<html>
<head>
  <title>Using WebForms Core</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
    <h1>WebForms Core in Dart</h1>
    Change to change color
    <select></select>
</body>
</html>
  ''';
}

Screenshot after running the Dart application

There is no JavaScript event handler in the Dart application.

There is no JavaScript DOM manipulation code.

There is no client-side framework.

The behavior is described through the WebForms class.

What Does the Server Actually Send?

The initial response contains the normal HTML page, followed by a WebForms Core command block:

<!--[web-forms]
ao<select>=whiteWhite
ao-=lightgreenLight Green
ao-=lightblueLight Blue
ao-=redRed
ao-=blueBlue
ao-=greenGreen
ao-=yellowYellow
ao-=orangeOrange
ao-=purplePurple
ao-=pinkPink
ao-=brownBrown
ao-=blackBlack
ao-=grayGray
Eb-=onchangeset-color
#=set-color
bc<body>=@$v<select>
{et=black@$v<select>
tc<body>=white
}e
tc<body>=black
-->

This is not JSON.

It is not an HTML attribute.

It is not a JavaScript program.

It is a WebForms Core Action Control command stream.

WebFormsJS detects the [web-forms] comment and processes it.

Then Something Interesting Happens

The browser receives the page.

WebFormsJS processes the commands.

The <select> element is populated.

The change event is connected.

The conditional behavior is prepared.

And the server-generated behavior becomes normal browser behavior.

The resulting DOM contains:

<select onchange="CommentBack(event, 'set-color', '')">
    <option value="white">White</option>
    <option value="lightgreen">Light Green</option>
    <option value="lightblue">Light Blue</option>
    ...
    <option value="black">Black</option>
    <option value="gray">Gray</option>
</select>

The important part is the execution model.

After the initial response, the interaction does not require another server request.

The browser executes the generated behavior locally.

In this example, the sequence is essentially:

Server
  ↓
WebForms Commands
  ↓
Initial HTML Response
  ↓
WebFormsJS
  ↓
DOM + Event
  ↓
Browser Execution

This is one of the important ideas behind WebForms Core.

The Server Defines the Behavior

Look at this part again:

form.startIndex("set-color");
form.setBackgroundColor("<body>", Fetch.getValue("<select>"));

form.isEqualTo("black", Fetch.getValue("<select>"));
    form.setTextColor("<body>", "white");
form.else_();
    form.setTextColor("<body>", "black");

The Dart server code describes the behavior.

It says:

When the set-color event occurs, get the value of the <select>.
Set the body background color to that value.
Check whether the selected value is black.
If it is black, make the text white.
Otherwise, make the text black.

The logic is authored on the server.

The execution happens in the browser.

That distinction is fundamental.

Server-Orchestrated UI

WebForms Core can be described as Server-Orchestrated UI.

The server does not continuously mirror the browser DOM.

It does not need a virtual DOM.

It does not require a separate frontend project.

Instead, the server sends executable UI commands, while WebFormsJS provides the browser-side runtime that executes them.

This creates a clear separation:

Server
Commander
    ↓
Commands
    ↓
Browser
Executor
    ↓
HTML DOM

The WebForms class is responsible for constructing the commands.

WebFormsJS is responsible for parsing and executing them.

But What About Server Requests?

WebForms Core does not require every interaction to be sent back to the server.

That is an important distinction.

There are two possible patterns.

Client execution

The server can send behavior that WebFormsJS executes directly in the browser.

For example:

User changes select
        ↓
WebFormsJS
        ↓
Read DOM value
        ↓
Change DOM

No additional server request is necessary.

Server execution

Other interactions can send data back to the server.

For example:

User submits form
        ↓
      Server
        ↓
   Dart WebForms
        ↓
 WebForms Commands
        ↓
     Browser

The server can then generate a new response containing only the UI operations required for that interaction.

This makes WebForms Core a hybrid system.

Some behavior can execute entirely in the browser.

Other behavior can involve the server.

A More Traditional Dart Example

Now consider a form.

The user enters a name, chooses a font size, enters a background color, and submits the form.

The Dart application can process the request:

var body = await request.readAsString();
var formData = Uri.splitQueryString(body);

if (formData['btn_SetBodyValue'] != null) {
  var name = formData['txt_Name'] ?? '';
  var backgroundColor = formData['txt_BackgroundColor'] ?? '';
  var fontSize = int.tryParse(formData['txt_FontSize'] ?? '16') ?? 16;

  final form = WebForms();

  form.setFontSize(InputPlace.tag('form'), '${fontSize}px');
  form.setBackgroundColor(InputPlace.tag('form'), backgroundColor);
  form.setDisabled(InputPlace.name('btn_SetBodyValue'), true);

  form.addTag(InputPlace.tag('form'), 'h3');
  form.setText(InputPlace.tag('h3'), 'Welcome $name!');

  return Response.ok(
    form.response(),
    headers: {
      'Content-Type': 'text/plain; charset=utf-8',
    },
  );
}

Notice what the server returns.

It does not have to return the entire HTML document.

It can return the commands required to update the existing page.

The server might effectively say:

Change the form font size.
Change the form background.
Disable the submit button.
Add an h3 element.
Set its text.

WebFormsJS executes those commands against the existing DOM.

Dart Without a Separate UI JavaScript Layer

This is where the Dart implementation becomes interesting.

The developer can write:

final form = WebForms();

form.setBackgroundColor(InputPlace.tag('form'), backgroundColor);
form.setDisabled(InputPlace.name('btn_SetBodyValue'), true);
form.addTag(InputPlace.tag('form'), 'h3');
form.setText(InputPlace.tag('h3'), 'Welcome $name!');

Instead of writing a separate JavaScript implementation for each of these operations, the Dart application constructs the WebForms Core command stream.

The browser runtime handles the execution.

WebForms Core Is More Than HTML Generation

It would be easy to look at this and think:

"This is just server-side HTML generation."

It is not.

HTML generation is only one part of the system.

The WebForms class can construct operations involving:

DOM manipulation
attributes
styles
events
conditions
DOM value retrieval
UI state
element creation
element replacement
workflow
client-side execution
server interaction

The important unit is not simply HTML.

It is the command.

The Commander–Executor Model

WebForms Core uses two major sides.

Commander

The WebForms class runs on the server.

In this case:

Dart
  ↓
WebForms

The Commander constructs the UI commands.

Executor

WebFormsJS runs in the browser.

It contains the runtime required to interpret and execute those commands.

WebFormsJS
  ↓
HTML DOM

Together:

Dart WebForms Commander
          ↓
    Action Controls
          ↓
      WebFormsJS
          ↓
       HTML DOM

This architecture allows different server-side languages to use the same browser execution model.

Dart is now another Commander.

Why Dart?

Dart is already used across server-side and application development, and the Shelf ecosystem provides a lightweight foundation for HTTP applications.

WebForms Core introduces another possibility for Dart web development:

Dart server
     +
WebForms Commander
     +
WebFormsJS
     =
Server-Orchestrated Web UI

Instead of introducing a large frontend framework for every interactive page, developers can keep more of the UI behavior in their server-side Dart code.

That does not mean every application should work this way.

It means there is another architectural option.

This Is Only the Beginning

The examples above are deliberately small.

The interesting question is what happens when the same model is applied to more complex interactions.

What if the server can construct:

multi-step UI workflows
conditional DOM operations
dynamic forms
event-driven interactions
partial UI updates
client-side state operations
complex DOM workflows
browser-side execution without additional requests

Then the WebForms class becomes more than a response builder.

It becomes a UI Commander.

And WebFormsJS becomes more than a JavaScript helper.

It becomes the Browser Executor.

WebForms Core for Dart

WebForms Core for Dart is now available as the webforms Dart package.

The package provides the WebForms Commander:

import 'package:webforms/webforms.dart';

Install it with:

dart pub add webforms

The architecture remains the same:

Dart
  ↓
WebForms Commander
  ↓
WebForms Core Commands
  ↓
WebFormsJS Runtime
  ↓
HTML DOM

The goal is simple:

Write the UI behavior in Dart. Let the browser execute it.

This brings WebForms Core's server-orchestrated UI architecture to Dart, allowing Dart applications to generate WebForms Core commands and control browser-side UI behavior through the WebFormsJS Runtime.

WebForms Core is now available for Dart.

WFC in Perl: A Server-Driven UI Approach for Perl

Elanat Framework — Tue, 15 Sep 2026 19:35:17 +0000

Perl has long been used for server-side web development, but modern web applications often rely heavily on JavaScript frameworks to manipulate the browser interface. WebForms Core (WFC) provides another approach: the server can generate UI commands that are executed by a browser runtime. This article demonstrates how WebForms Core can be used with Perl and the Mojolicious framework to build an interactive web interface while keeping the UI logic on the server.

What is WebForms Core?

WebForms Core is a server-side UI manipulation technology created by Elanat that allows a server application to generate commands for manipulating the HTML DOM and controlling UI behavior in the browser. Instead of requiring a separate frontend application or a JavaScript framework for every interaction, the server uses the WebForms class to construct WebForms Core commands, and the WebFormsJS browser runtime receives and executes those commands. The architecture separates the server-side Commander from the browser-side Executor: the server generates UI commands, while WebFormsJS parses and executes them against the DOM. WebForms Core is not limited to forms or CRUD operations and can be used for general UI manipulation, automation, and interactive web applications.

WebForms Core commands are generated by methods of the WebForms class, so developers do not need to construct the command syntax manually. Elanat refers to these commands as "Action Controls".

WebForms Core in Perl

The Perl implementation of WebForms Core provides the WebForms class for generating WebForms Core commands from a Perl application.

The architecture can be summarized as:

Perl Application
      |
      v
WebForms Class
      |
      | WebForms Core Commands
      |
      | HTTP Response
      |
      v
  WebFormsJS
      |
      v
  HTML DOM

The important point is that the Perl application does not need to directly manipulate the browser DOM. Instead, the server creates commands describing the required UI operations.

For example, the server can instruct the browser to change a font size, change a background color, disable a button, add an element, and set its text.

The WebForms Class

The WebForms class is the server-side Commander of WebForms Core.

In Perl, an application creates a WebForms object and uses its methods to construct UI commands:

my $form = WebForms->new;

$form->set_font_size(InputPlace::tag('form'), "${fontSize}px");
$form->set_background_color(InputPlace::tag('form'), $backgroundColor);
$form->set_disabled(InputPlace::name('btn_SetBodyValue'), 1);

$form->add_tag(InputPlace::tag('form'), 'h3');
$form->set_text(InputPlace::tag('h3'), "Welcome $name!");

The InputPlace helpers specify which HTML elements should be targeted. For example, InputPlace::tag('form') selects the form element, while InputPlace::name('btn_SetBodyValue') selects an element by its name attribute.

The commands are then returned as part of the HTTP response:

$c->render(text => $form->response());

This makes the WebForms class a server-side UI command generator. The Perl application determines what should happen to the interface, while the browser runtime performs the actual DOM operations.

WebFormsJS

WebFormsJS is the browser-side runtime of WebForms Core.

It is included in the HTML page as a JavaScript module or script and is responsible for receiving, parsing, and executing WebForms Core commands in the browser.

For example:

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

WebFormsJS acts as the Executor between the server-generated commands and the browser DOM.

The complete execution model is therefore:

Server
  |
  | WebForms commands
  |
  v
HTTP Response
  |
  v
WebFormsJS
  |
  | DOM operations
  |
  v
Browser

This means that the Perl application does not need to generate custom JavaScript for every UI operation. The server can use the WebForms class to express the required UI changes, while WebFormsJS handles their execution.

Installing WFC from CPAN

The Perl implementation of WebForms Core is distributed as the WFC package.

After installing Perl and cpanm, the package can be installed with:

cpanm WFC

The package provides the WebForms Core Perl classes required by the application.

For example, the application can load the WebForms implementation with:

use WebForms;

The CPAN distribution is useful when WebForms Core is installed as a dependency of a Perl web application rather than copied directly into the project.

Using WebForms Core with Mojolicious

Mojolicious is a Perl web framework that can be used to build the server application. WebForms Core can be integrated into a Mojolicious application by creating a WebForms object inside a route and returning its generated response.

The following example demonstrates a complete interaction.

The user enters a name, font size, and background color. When the form is submitted, Perl reads these values, creates WebForms Core commands, and returns them to the browser.

use Mojolicious::Lite;

use WebForms;

post '/' => sub {
    my $c = shift;

    my $name = $c->param('txt_Name');
    my $backgroundColor = $c->param('txt_BackgroundColor');
    my $fontSize = $c->param('txt_FontSize');

    my $form = WebForms->new;

    $form->set_font_size(InputPlace::tag('form'), "${fontSize}px");
    $form->set_background_color(InputPlace::tag('form'), $backgroundColor);
    $form->set_disabled(InputPlace::name('btn_SetBodyValue'), 1);

    $form->add_tag(InputPlace::tag('form'), 'h3');
    $form->set_text(InputPlace::tag('h3'), "Welcome $name!");

    $c->render(text => $form->response());
};

get '/' => sub {
    my $c = shift;

    $c->render(text => <<'HTML');
<!DOCTYPE html>
<html>
<head>
  <title>Using WebForms Core in Perl</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
    <form method="post" action="/">
        <label for="txt_Name">Your Name</label>
        <input name="txt_Name" id="txt_Name" type="text" />
        <br>
        <label for="txt_FontSize">Set Font Size</label>
        <input name="txt_FontSize" id="txt_FontSize" type="number" value="16" min="10" max="36" />
        <br>
        <label for="txt_BackgroundColor">Set Background Color</label>
        <input name="txt_BackgroundColor" id="txt_BackgroundColor" type="text" />
        <br>
        <input name="btn_SetBodyValue" type="submit" value="Click to send data" />
    </form>
</body>
</html>
HTML
};

app->start;

How the Example Works

The initial GET / request returns the HTML page. The page contains a normal HTML form and loads web-forms.js.

No WebForms Core-specific attributes are required in the form:

<form method="post" action="/">

When the user submits the form, the POST / route receives the submitted values:

my $name = $c->param('txt_Name');
my $backgroundColor = $c->param('txt_BackgroundColor');
my $fontSize = $c->param('txt_FontSize');

The server then creates a WebForms object:

my $form = WebForms->new;

The UI operations are defined on the server:

$form->set_font_size(InputPlace::tag('form'), "${fontSize}px");
$form->set_background_color(InputPlace::tag('form'), $backgroundColor);
$form->set_disabled(InputPlace::name('btn_SetBodyValue'), 1);

The server also creates an h3 element and sets its text:

$form->add_tag(InputPlace::tag('form'), 'h3');
$form->set_text(InputPlace::tag('h3'), "Welcome $name!");

Finally, the generated WebForms Core response is returned:

$c->render(text => $form->response());

WebFormsJS receives this response in the browser and executes the generated commands. The result is that the form's font size and background color change, the submit button becomes disabled, and a new heading containing the user's name is added to the page.

Server-Driven UI

This example demonstrates the basic Server-Driven UI model provided by WebForms Core.

The browser does not need a separate frontend application to implement the UI logic described by WebForms Core commands. The server determines the UI operations:

User Input
    |
    v
Mojolicious
    |
    v
WebForms
    |
    | UI Commands
    |
    v
HTTP Response
    |
    v
WebFormsJS
    |
    v
   DOM

This is different from the traditional approach where the server primarily returns HTML while JavaScript code in the frontend contains the logic for manipulating that HTML.

With WebForms Core, the server can orchestrate UI operations through commands while WebFormsJS provides the browser-side runtime that executes those commands.

Building a Memory Game with WebForms Core

WebForms Core is not limited to traditional forms or CRUD interfaces. The following example demonstrates a small memory card game implemented with Perl, Mojolicious, and WebForms Core.

The game contains eight pairs of emoji cards, for a total of 16 tiles. The cards are shuffled on the server when a new game starts. The browser then uses WebForms Core commands to reveal cards, compare pairs, count moves and matches, and reset the game.

This example is particularly useful for demonstrating that WebForms Core can handle interactive browser behavior without requiring a separate frontend application.

Memory Tiles Example

use Mojolicious::Lite;
use List::Util qw(shuffle);

use WebForms;

get '/' => sub {
    my $c = shift;

    my @cards = shuffle(
        qw(
            🍎 🍎
            🍋 🍋
            🍊 🍊
            🍉 🍉
            🍇 🍇
            🥝 🥝
            🍓 🍓
            🍒 🍒
        )
    );

    my $html = '';

    for my $i (0 .. $#cards) {
        $html .= qq{<button id="tag-$i" class="tile" data-card="$cards[$i]">?</button>\n};
    }

    my $form = WebForms->new;

    $form->set_comment_event("<button>*", HtmlEvent::OnClick, "play");
    $form->set_comment_event("reset", HtmlEvent::OnClick, "reload");
    $form->remove_all_save();

    $form->start_index("play");

    # First tile
    $form->not_exist(Fetch::save("first-card"));

    $form->start_bracket();
    $form->save_id('$', "first-id");
    $form->save_attribute('$', "data-card", "first-card");
    $form->insert_class('$', "selected");
    $form->set_disabled('$', 1);
    $form->set_text('$', Fetch::get_attribute('$', "data-card"));
    $form->wf_break();

    $form->end_bracket();

    $form->increase("moves", 1);

    # Second tile
    $form->set_class('$', "selected");
    $form->set_disabled('$', 1);
    $form->set_text('$', Fetch::get_attribute('$', "data-card"));

    # Match
    $form->is_equal_to(
        Fetch::save("first-card"),
        Fetch::get_attribute('$', "data-card")
    );
    $form->start_bracket();

    $form->increase("matches", 1);
    $form->remove_save("first-card");
    $form->set_text("result", "Good");

    $form->is_equal_to("8", Fetch::get_text("matches"));
    $form->message("🎉 You Win!");

    $form->wf_break();

    $form->end_bracket();

    # No match
    $form->delay(800);

    # Return first card
    $form->set_text(Fetch::save("first-id"), "?");
    $form->set_class(Fetch::save("first-id"), "");
    $form->set_disabled(Fetch::save("first-id"), 0);
    $form->remove_save("first-card");

    # Return second card
    $form->set_text('$', "?");
    $form->set_class('$', "");
    $form->set_disabled('$', 0);

    $form->set_text("result", "Try Again");
    $form->set_text("moves", Fetch::get_text("moves"));

    $form->start_index("reload");
    $form->reload_page();

    $c->render(text => $form->export_to_html_comment() . <<HTML);
<!DOCTYPE html>
<html>
<head>
    <title>Memory Tiles in Perl</title>
    <script type="module" src="/script/web-forms.js"></script>
    <style>
        body {
            font-family: sans-serif;
            text-align: center;
        }

        #board {
            display: grid;
            grid-template-columns: repeat(4, 80px);
            gap: 10px;
            justify-content: center;
            margin: 30px auto;
        }

        .tile {
            width: 80px;
            height: 80px;
            font-size: 32px;
            cursor: pointer;
        }

        #reset {
            cursor: pointer;
        }
    </style>
</head>
<body>

<h1>Memory Tiles</h1>

<div id="board">
$html
</div>

<p>Moves: <span id="moves">0</span></p>
<p id="result"></p>
<p>Matches: <span id="matches">0</span></p>
<b id="reset">New Game</b>
</body>
</html>
HTML
};

app->start;

How the Memory Game Works

The server initially creates the game board by generating pairs of emoji cards:

my @cards = shuffle(
    qw(
        🍎 🍎
        🍋 🍋
        🍊 🍊
        🍉 🍉
        🍇 🍇
        🥝 🥝
        🍓 🍓
        🍒 🍒
    )
);

The shuffle function randomizes the cards for each new game. Perl then generates the HTML buttons for the board.

The important part of the example is that the game behavior is defined through the WebForms class.

Registering Events

The following commands associate browser events with WebForms Core command indexes:

$form->set_comment_event("<button>*", HtmlEvent::OnClick, "play");
$form->set_comment_event("reset", HtmlEvent::OnClick, "reload");

Every tile button is associated with the play command sequence, while the reset element is associated with the reload sequence.

The generated commands are placed into the HTML response using:

$form->export_to_html_comment()

This allows WebFormsJS to discover the server-generated commands from the HTML response.

Selecting the First Card

The game uses WebForms Core Save values to remember information about the first selected card:

$form->not_exist(Fetch::save("first-card"));

When no first card exists, the clicked tile becomes the first selected card.

The example stores both the card identifier and its data-card value:

$form->save_id('$', "first-id");
$form->save_attribute('$', "data-card", "first-card");

The tile is then visually selected and disabled:

$form->insert_class('$', "selected");
$form->set_disabled('$', 1);
$form->set_text('$', Fetch::get_attribute('$', "data-card"));

The $ InputPlace refers to the current target element.

Comparing the Cards

When the second tile is selected, the game compares its data-card value with the saved value from the first tile:

$form->is_equal_to(
    Fetch::save("first-card"),
    Fetch::get_attribute('$', "data-card")
);

If the values are equal, the match counter is increased:

$form->increase("matches", 1);
$form->remove_save("first-card");
$form->set_text("result", "Good");

When all eight pairs have been matched, the game displays a winning message:

$form->is_equal_to("8", Fetch::get_text("matches"));
$form->message("🎉 You Win!");

Handling a Failed Match

If the two cards do not match, the commands wait for 800 milliseconds:

$form->delay(800);

The first card is then restored using the saved element identifier:

$form->set_text(Fetch::save("first-id"), "?");
$form->set_class(Fetch::save("first-id"), "");
$form->set_disabled(Fetch::save("first-id"), 0);

The second card is restored using the current target:

$form->set_text('$', "?");
$form->set_class('$', "");
$form->set_disabled('$', 0);

The result is then updated:

$form->set_text("result", "Try Again");
$form->set_text("moves", Fetch::get_text("moves"));

Starting a New Game

The reload command index is associated with the reset element:

$form->start_index("reload");
$form->reload_page();

When the player selects New Game, WebFormsJS executes the generated reload command and the server creates a new randomized board.

Screenshot of Memory Tiles Game

What This Example Demonstrates

The memory game demonstrates several important WebForms Core capabilities in a single Perl application:

Event registration with set_comment_event
Command indexes with start_index
Conditional execution with is_equal_to
Temporary browser-side values with Save
DOM targeting with InputPlace
Attribute and text retrieval with Fetch
DOM modification
Class manipulation
Element disabling
Counters and state changes
Delayed execution
Browser messages
Page reload
Server-generated commands embedded in HTML comments

Most importantly, the example demonstrates that WebForms Core can be used for interactive browser applications, not only traditional server forms.

The server defines the game behavior and generates the WebForms Core command sequence. WebFormsJS then executes that sequence in the browser.

This provides a different model from a conventional JavaScript application: instead of implementing the complete game logic in a frontend JavaScript application, the server can construct the interaction flow through WebForms Core commands.

Why Use WebForms Core with Perl?

WebForms Core gives Perl developers another option for building interactive web interfaces.

A Perl application can keep its application and UI orchestration logic on the server while using a browser runtime for command execution. The developer does not need to introduce a separate React, Vue, or similar frontend project simply to perform server-controlled UI operations.

This approach is particularly interesting for Perl applications that already have server-side business logic and want to add richer browser interaction without moving the entire application UI layer into a JavaScript framework.

WebForms Core also keeps the HTML document model visible. The application works with HTML elements and selectors rather than replacing the HTML document with a separate component model.

Conclusion

WebForms Core provides a Server-Driven UI approach for Perl by introducing a server-side WebForms class and a browser-side WebFormsJS runtime.

The Perl application acts as the Commander: it determines which UI operations should occur and generates the corresponding commands. WebFormsJS acts as the Executor: it receives those commands and performs the required operations on the browser DOM.

With the WFC package available through CPAN, this architecture can be used directly from Perl applications such as Mojolicious. The result is a model in which Perl remains responsible for application and UI orchestration logic, while the browser executes the commands through WebFormsJS.

DEV Community: Elanat Framework

WebForms Core 2.2 Development Has Begun

A New Stateless Architecture for Server-Orchestrated UI

A More Expressive WebForms Model

Isolated DOM Operations

Rendering and State Management

Snapshot and Rollback

Hash-Based State Detection

Rendering Without Mirroring the DOM

Formatting Data

Arithmetic Operations

Text Operations

Regex-Based Tag Selection

Comments and Debugging

Middleware

From Commands to Operations

A Server-Orchestrated Rendering Architecture

The Direction of WebForms Core 2.2

Related links

Elanat CMS Will Be Retired After Version 2.2: Introducing Gloria, a New Generation CMS

Why Are We Retiring Elanat CMS?

From Elanat CMS to Gloria

Gloria Will Continue the Elanat CMS Philosophy

The Elanat Ecosystem

Why a New Name?

A Clearer Name and Identity

The Elanat Logo Will Continue

What Happens to Elanat CMS 2.2?

A New Beginning

Repository Transition

From the Past to the Next Generation

Go WebAssembly Meets WebForms Core 2.1

What is WebForms Core?

Go WebAssembly

Creating the Go WebAssembly Project

Go WebAssembly Runtime

Install the Go Package

WebFormsJS Installation via Package

Using WebForms Core from Go

add

setData

getHtml

The WebForms Class in Go

Go WebAssembly and JavaScript

Using Go WebAssembly from WebForms Core

HTML

The Interesting Part

WASM Event With Output

Where Does the Execution Take Place?

Go Is an Execution Layer

No Custom JavaScript Required for These UI Operations

Standard HTML Remains the UI

Go and WebForms Core

WebAssembly Does Not Have to Replace the UI Architecture

Go WebAssembly and WebFormsJS

WebForms Core 2.1 and WebAssembly Languages

Final Result

Conclusion

Related Links

Rust WebAssembly with WebForms Core 2.1

What is WebForms Core?

Rust WebAssembly

Rust in Crates.io

Two Rust WebAssembly Approaches

1. wasm-bindgen

2. Raw WebAssembly

Creating the Rust Project

Using WebForms Core from Rust

Rust with wasm-bindgen

Building the wasm-bindgen Module

Raw WebAssembly with Rust

Passing Strings to Raw WebAssembly

Returning WebForms Core Responses

Using Rust WASM from WebForms Core

Three Rust WASM Methods

HTML

The WASM Method as a Command Execution Source

WASM Event With Output

One WebForms Core API, Different WASM Models

wasm-bindgen vs Raw WebAssembly

`add`

`setData`

`getHtml`

`add`

`setData`

`getHtml`