Client-Side ASP.NET MVC Runtime for WebAssembly

[sultanaalyami]

Summary

This proposal introduces a client-side ASP.NET MVC runtime that executes Controllers, Razor Views, Routing, EF Core (SQLite), SignalR, and Identity entirely inside a WebAssembly Web Worker — with zero server dependency at runtime.

Developers write standard MVC code — Controllers, .cshtml Views, ViewData/ViewBag/TempData, Tag Helpers, Areas — and the SDK compiles it into static files deployable to any CDN, edge network, or embedded WebView.

A working implementation exists today:
NetWasmMvc.SDK + Cepha.CLI on NuGet — source at sbay-dev/NetWasmMVCRuntime
website sbay-dev.github.io

---

The Problem

ASP.NET MVC is the most widely adopted .NET web programming model — yet it has no client-side story.

• MVC requires a server. Developers with large MVC codebases have no path to deploy as static SPAs or to edge runtimes without a full rewrite.
• No offline-first MVC. Server-rendered MVC cannot function without connectivity. There is no PWA-capable MVC with local Controllers, Views, and database access.
• No "write once, deploy anywhere." You must choose between server-rendered MVC (requires infrastructure) or Blazor (different programming model). No option to run the same code as a browser SPA, a Node.js API, or an edge Worker.
• Competitive gap. Next.js, Nuxt, and SvelteKit all support static-site generation and edge deployment. .NET MVC has no equivalent.

---

Proposed Solution

A new SDK target that compiles ASP.NET MVC for execution inside a WebAssembly Web Worker:

<Project Sdk="Microsoft.NET.Sdk.WebAssembly.Mvc">
  <PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
  </PropertyGroup>
</Project>

The developer writes standard MVC code — no new paradigm to learn:

public class HomeController : Controller
{
    public IActionResult Index()
    {
        ViewData["Title"] = "Welcome";
        return View();
    }

    [HttpPost]
    public IActionResult Contact(ContactForm form)
    {
        if (!ModelState.IsValid) return View(form);
        _db.Messages.Add(new Message { Name = form.Name, Body = form.Body });
        _db.SaveChanges();
        TempData["Success"] = "Message saved locally.";
        return RedirectToAction("Index");
    }
}

dotnet publish produces static files. No ASP.NET server required at runtime.

How it works: The .NET runtime boots inside a Web Worker, keeping the UI thread free. An MVC engine handles controller discovery, route matching, and action invocation. A pattern-matching Razor engine renders .cshtml views from embedded resources. The rendered HTML is sent to the main thread as frames applied via requestAnimationFrame. SQLite databases and session state persist to the Origin Private File System (OPFS). All C#↔JS communication uses JSImport/JSExport — no dependency on Blazor's infrastructure.

What's included

• Full MVC pipeline — Controller base class, ViewData/ViewBag/TempData/ModelState, ViewResult/PartialViewResult/JsonResult/RedirectResult, attribute routing, [Area], [ApiController], convention-based routing.
• Razor rendering (no Roslyn) — @Model, @ViewData, @if/@foreach, @RenderBody(), @RenderSection(), @Html.PartialAsync(), asp-controller/asp-action tag helpers.
• EF Core + SQLite in WASM — Full LINQ, migrations, relationships. Database persisted to OPFS.
• Client-side Identity — PBKDF2-SHA256 hashing, HMAC-signed session tokens, fingerprint binding, account lockout, cross-tab auth sync.
• In-process SignalR — Hub discovery, Clients.All/Caller/Others/Group(), connection management — all in-process.
• Dual hosting — Same code runs as a browser SPA or a Node.js/Cloudflare Workers/Edge API server.
• CLI tooling — cepha new, cepha dev, cepha publish, cepha kit (Cepha.CLI).

How this complements Blazor

This is not a replacement for Blazor. Blazor excels at rich interactive UIs with fine-grained reactivity. MVC WASM excels at document-oriented apps, admin panels, and CRUD applications where the existing MVC skillset should transfer directly to client-side deployment — without rewriting views as components. Both models share the same .NET WASM runtime and could coexist.

---

Why This Belongs in .NET 11

1. The runtime foundation is ready. .NET 10 ships mature WebAssembly support: dotnet.js, Web Workers, JSImport/JSExport, WASM-compiled SQLite. What's missing is the MVC engine layer on top.

2. NativeAOT for WASM is coming. .NET 11 is expected to advance NativeAOT/Trimming for WebAssembly, which would reduce the current ~15-25MB bundle to a competitive size. This proposal aligns with that timeline.

3. Edge computing is mainstream. Cloudflare Workers, Deno Deploy, Vercel Edge Functions are standard deployment targets. .NET 11 is the window to establish MVC as a viable edge framework.

4. Developer demand is real. MVC is the WIP: repo consolidation scouting kick-off - make clr build locally on Windows #1 ASP.NET programming model by adoption. Developers want their existing skills to work in new deployment targets — not a new paradigm.

5. Feasibility is proven. The reference implementation is published on NuGet with CI/CD, covering Controllers → Views → EF Core → Identity → SignalR. This is not theoretical.

---

What We Are Asking from the .NET Team

We are not asking for a massive new framework — just targeted infrastructure:

Experimental / .NET 11 Preview

1. Microsoft.NET.Sdk.WebAssembly.Mvc SDK target — embed .cshtml as resources, link SQLite natively, produce static SPA output. (~200 lines of MSBuild in our implementation.)
2. Lightweight MvcEngine for WASM — controller discovery, route matching, action invocation without the full server pipeline. (Single file in our implementation.)
3. Razor template provider contract (ITemplateProvider / IRazorTemplateEngine) — rendering .cshtml from embedded resources.
4. dotnet new mvc-wasm template — scaffolding via the standard template system.

Post-Preview

5. NativeAOT/Trimming for smaller bundles.
6. Visual Studio / VS Code F5 debugging in WASM Workers.
7. Blazor interop — embed MVC views inside Blazor components and vice versa.

What we are NOT asking for: ❌ Changes to the existing MVC server pipeline · ❌ Changes to Blazor · ❌ A new component model · ❌ Deprecation of any existing feature.

---

Reference Implementation

📦 Repository: github.com/sbay-dev/NetWasmMVCRuntime

NuGet packages:

• SDK: NetWasmMvc.SDK — <Project Sdk="NetWasmMvc.SDK/1.0.6">
• CLI: Cepha.CLI — dotnet tool install --global Cepha.CLI

Key source files: MvcEngine.cs · RazorTemplateEngine.cs · Controller.cs · SignalREngine.cs · Identity/ · CephaApp.cs · main.js · Sdk/

---

Call for Feedback

We'd love to hear from the community and the .NET team:

1. Is this worth supporting officially? Do enough developers want MVC in the browser to justify framework-level investment?
2. Should this start as an experimental SDK? Similar to how Blazor started — let the community validate the model first.
3. What MVC features are essential for a v1? The current implementation covers Controllers, Views, EF Core, Identity, and SignalR. What else would you need?
4. Bundle size concerns? The ~15-25MB size is the biggest barrier. Would NativeAOT improvements in .NET 11 make this viable for your use case?
5. Edge deployment interest? Is running .NET MVC on Cloudflare Workers / Deno Deploy compelling for your team?

If you find this idea interesting, please 👍 this discussion and share your use cases. Community signal helps the .NET team prioritize.

---

Based on WasmMvcRuntime — an open-source client-side ASP.NET MVC runtime for WebAssembly, published on NuGet and actively maintained.

Originally posted by @sultanaalyami in dotnet/aspnetcore#65501

[danroth27]

Hi @sultanaalyami. Our web UI investments in ASP.NET Core are currently focused on Blazor, but we still support and maintain MVC and it's great to see the community experiment with the MVC model for client-side UI. I don't think this is something we'll bring directly into the platform, but it's certainly something the community can continue to experiment with. I believe all of the infrastructure pieces you mentioned can be handled outside of the framework, but if there are specific areas where you think better extensibility or composability are needed, please let us know. Regarding Native AOT specifically, that will generally help with runtime performance but will typically increase download size compared to the Jiterpreter approach. What makes AOT smaller for server runtimes is really IL trimming, which you'll want to do for client-side apps whether you AOT compile the code to WebAssembly or not.

[mudassir523]

Thank you for the clarification.

Just to understand better — if someone wants to experiment with MVC-style client-side UI outside the framework, would the recommended approach be building it as a separate library on top of ASP.NET Core, or extending existing Blazor infrastructure?

Also, regarding Native AOT and IL trimming, are there any official guidelines or best practices for optimizing client-side apps compiled to WebAssembly?

[sultanaalyami]

This is a tracking sub-issue for following up on the progress and discussion related to the upstream issue in the .NET Runtime repository:

Related issue: Client-Side ASP.NET MVC Runtime for WebAssembly (#125136)

Please refer to the linked issue for technical details, the proposed solution, and ongoing feedback involving the client-side ASP.NET MVC runtime for WebAssembly.

This sub-issue will help ensure synchronization between our project and any advancements or updates from the upstream thread.

Action items:

• Monitor updates and activity on dotnet/runtime#125136
• Evaluate how any discussions or changes may impact our work
• Provide project-specific feedback if relevant

[sultanaalyami]

🚀 Official Update

We are excited to share that ASP.NET MVC now runs fully client‑side on WebAssembly, powered by the NetWasmMVC toolchain and hosted through Blazor.

This milestone required significant effort, research, and engineering work — but the results are now live through two official templates:

🔐 Core Identity Template

A complete MVC + Identity experience running entirely in the browser:
https://cepha-secure.pages.dev/

📱 SPA + PWA Template

A single‑page MVC application with full PWA capabilities and offline support:
https://is-bay-supply.pages.dev/

Both templates are fully operational.
Remaining server‑side adjustments in CephaKit are currently being finalized.

❤️ Support the Project

This work has required substantial time and resources.
If you’d like to support continued development, improvements, and maintenance, you can do so here:
https://cepha-store.2sa.workers.dev/

This marks the first production‑grade demonstration of client‑side MVC running on WebAssembly.