Performance Comparison: React vs WebForms Core

Source: Dev.to

Overview

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

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

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

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

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

1️⃣ Initial Load Phase

React

In a typical React application the following occurs:

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

Even in optimized projects you usually see:

• One initial HTML request
• Multiple JS requests (bundle, runtime, vendor chunks)
• CSS and other assets

Result

WebForms Core

In WFC the server sends a standard HTML page. Optionally a lightweight WebFormsJS file is added, but there is no heavy bundle and no mandatory build pipeline.

In the simplest case:

• One HTML request
• One small JS request (if WebFormsJS is used)

Result

2️⃣ User Interactions

Scenario A – Pure Client‑Side Interaction

WFC Example (KeyUp without server call)

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

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

    Write(form.ExportToHtmlComment());
}

Server output (sent to the client)

Execution model

Event → Direct DOM manipulation

React Equivalent

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

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

Execution model

Event → setState → Virtual DOM diff → Patch DOM

Observations

• React maintains state, runs a virtual‑DOM diff, and triggers a re‑render cycle.
• WFC uses the server‑side state engine, performs no diff algorithm, and updates the DOM directly.
• For simple interactions the CPU overhead is lower with WFC.

Scenario B – Interaction with Server

React

// Typical form submission
fetch("/api/contact", {
  method: "POST",
  body: data
});

Standard SPA pattern

1. AJAX request
2. JSON response
3. State update
4. Re‑render

In larger apps this expands to:

• Multiple API endpoints
• Parallel requests
• Polling or WebSocket connections

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

WebForms Core

WFC preserves the traditional form model:

POST → server → INI‑style response → DOM patch

Server response (compact command instructions)

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

Only the changed parts are sent; no full HTML is returned and no large JSON state tree is transmitted.

Result: Bandwidth consumption is lower than a full page reload and typically lighter than API‑heavy SPA responses.

3️⃣ Request Patterns in Real Applications

React (SPA Model)

• Large bundle downloaded once
• Dozens or hundreds of subsequent API calls
• Fully dependent on backend APIs

Benefit: No full page reloads
Cost: Continuous API dependency and network chatter

WebForms Core

Two possible patterns:

1. Pure client‑side interaction – no server calls.
2. Lightweight round‑trip form‑based interaction – only the necessary command instructions travel.

In many simple UI cases no server request is required. In data‑driven cases the number of calls is usually fewer than in API‑heavy SPAs, and the interaction is form‑based rather than endpoint‑driven.

4️⃣ Bandwidth Consumption

5️⃣ JSX and Build Requirement

React

• Build process is practically mandatory

  • JSX must be transpiled (Babel, TypeScript, etc.)
  • Modules need bundling (Webpack, Vite, etc.)
  • Optimizations (tree‑shaking, minification) are applied at build time

• HTML is written inside JavaScript → UI structure depends on runtime execution.

• Without JavaScript, nothing renders.

WebForms Core

• HTML remains standard, no JSX.
• No mandatory build step – pages can be served directly from the server.
• View is independent and fully inspectable.
• Server logic stays separate from markup.

6️⃣ Development Model Perspective

React

• UI = function(state) – the UI is a pure function of the application state.
• State is usually held client‑side (or via a global store).
• Developers think in terms of components, hooks, and immutable updates.

WebForms Core

• UI = server‑driven description – the server emits a lightweight description of what should change on the client.
• State lives on the server; the client only receives incremental commands.
• Developers work with familiar HTML + server‑side event wiring, similar to classic WebForms but with a modern, lightweight protocol.

TL;DR

Both approaches have their place; the choice hinges on the network‑budget, latency tolerance, and architectural preferences of the project.

Driven

• Re‑render‑driven
• Data‑centric architecture

WebForms Core

• UI = HTML
• Behavior = commands
• Event‑driven
• Command‑based execution

7️⃣ Final Technical Summary

If the evaluation focuses strictly on network and bandwidth:

React

• Larger initial payload
• API‑heavy interaction model
• Client‑side state engine

WebForms Core

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

Summary of Network & Structural Behavior

Conclusion

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

WebForms Core represents a hybrid model that can:

• Operate fully client‑side
• Communicate with minimal bandwidth using compact command instructions
• Avoid complex client state engines
• Eliminate mandatory build pipelines

From a network and bandwidth perspective

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