Enter fullscreen mode

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.

AssemblyScript WebAssembly Meets WebForms Core 2.1