16:56 Wednesday, 18 March 2026

.NET and WebAssembly beyond the browser

There is a popular misconception that WebAssembly is something one would use with front-end, for example with Blazor. While this is partially true, WebAssembly is more interesting than that, because it is an universal, portable runtime and it is becoming more and more important for all applications.

I will show you what WebAssembly is, what problem it solves and how it relates to both front-end and back-end applications. I will finally present a use case which can be implemented using WebAssembly on back-end.

What problem does WebAssembly solve?

WebAssembly solves the problem of running portable, sandboxed code safely across different platforms, let it be Windows, Unix, iOS or Android. WASM runs in an isolated sandbox, which gives us some advantages, but creates some interesting challenges as well. The advantages are for example: portability, security.

Why is the problem of running portable sandboxed code relevant for front-end and back-end?

Why does WASM matter for front-end?

As WebAssembly code runs in sandbox and is faster than JavaScript, it is very common to use it for running client-side applications in browser.

It was added to web browsers because JavaScript wasn't good enough as compilation target. Before WASM, if you wanted to run something heavy on front-end, you had to compile it to JavaScript. In the older days, users of Microsoft stack would use Internet Explorer with VBS. This allowed to execute server side code on the client. Unfortunately, this was dangerous, as it allowed arbitrary code execution on your host.

If you recognize Blazor , you may know that using WebAssembly is becoming more and more ubiquitous for running .NET code on client side. Microsoft has its implementation of running .NET in browser via WebAssembly and JavaScript and calls it Blazor. You should be able to see the simplified architecture of Blazor on the image below. Microsoft implements running .NET and WebAssembly. It is called Blazor. This is WebAssembly we know of and talk about. It works like this: After an user requests website, HTML loads in your browser, then .NET Runtime is loaded to WebAssembly. The .NET Runtime runs the code you, as developer, provide.

We've discussed why it is important for front end. WebAssembly was created to run web-based applications, hence the name. But we said, it was a portable and universal execution layer. We have now enough information to get to the point. Why does it matter?

Use case

Let's turn our back on front-end for now and consider a use case: Imagine an Enterprise Resource Planning system where multiple tenants can upload custom business logic in form of binary files. Security becomes a problem, as a tenant might want to upload malicious code to our system.

Figure: Back-end running multiple tenants. Each tenant runs their own plugin with custom business logic.

In some systems it may be possible for tenants to send a compiled file with business logic. These files may potentially contain harmful code. Therefore it is important to apply appropriate security precautions.

Each solution have advantages and disadvantages.

These tenants may trade different types of goods, from shoes to eggs, and may have lots of different customers, from Germany to China. Imagine now, that some tenants want to implement different business logic. For example: a German tenant might want to lower prices by 20% before Christmas, while a Chinese tenant might want to do the same before the Chinese New Year. In each cases, logic may be very different and based on specific conditions.

Beyond the browser

WebAssembly solves this problem as a portable and sandboxed execution layer. Unlike other solutions, like AOT.NET, it was designed with security in mind. Instead of sandboxing .NET, we run .NET in a sandbox.

No engineer would say that there are perfect solutions. Even though we have some advantages here, we need to be aware of some drawbacks as well. The byte code is independent on what we run it on, but the ecosystem is relatively small, so applications like business logic are fine.

Benefits / drawbacks with WebAssembly

Looking at WebAssembly through costs, we obtain isolation, but we make our lives more complicated. We have portability, but we loose mature ecosystem. And compared to containers, WASM wakes up faster.

• Lighter than Containers
• Can be much better secured against evil code
• Most languages can be compiled into WASM
• Strong isolation (like VM)

But:

• Not as flexible, and poorer software collection
• Less mature tooling

What happens afterwards?

Today we've gone from MVC, Minimal APIs and FastEndpoints. All different ways to structure how we run the process.

Compared to MVC / Minimal API / FastEndpoints WASM is not your next controller model. It flips the question: what if your endpoint logic does not run in your process at all?

The relationship between WebAssembly and .NET is a broad subject and we do only have enough space to introduce you to the subject and mention one use case.

There is more. We did not compared WASM as container vs Docker, or Java vs .NET vs WASM vs AOT.NET.

There are some other interesting use cases for tenants, for example secured custom business logic, which I would like to implement some day, fast and effective process isolation, custom business logic or policy engines.

Finally, we now see that WebAssembly is a runtime framework. It solves the problem of running portable and sandboxed code safely across different platforms and .NET runs on top of it, both in front-end and back-end scenarios. It is real, but it's not your real back-end model yet.