Working with WebAssembly and C#: Advanced Level in .NET

Introduction to WebAssembly and C#: From Theory to Practice

WebAssembly (WASM) has become the standard for high-performance web applications. The .NET ecosystem offers powerful tools for compiling C# code to WASM, opening up opportunities for porting complex algorithms, libraries, and even entire frameworks to the browser. At an advanced level, working with WebAssembly and C# requires understanding not only basic compilation but also the nuances of memory management, JavaScript interop (JS Interop), binary file size optimization, and debugging.

In this article, we will explore key aspects that will allow you to go beyond simple examples and create efficient, scalable WASM applications in C#.

1. Compiling and Deploying .NET to WebAssembly: Advanced Methods

To compile C# to WASM, the Mono/WASM runtime is used, embedded in Blazor WebAssembly or available via .NET WASM Build Tools. At an advanced level, it is important to control the build process.

1.1. Build Size Optimization and AOT Compilation

By default, Blazor uses JIT compilation inside the WASM environment, which results in loading the full Mono runtime (~2-3 MB compressed). To reduce size, you can use AOT (Ahead-of-Time) compilation. It compiles your C# code directly into WASM instructions, eliminating the need for JIT.

<!-- In the .csproj file -->\n<PropertyGroup>\n  <RunAOTCompilation>true</RunAOTCompilation>\n  <WasmDebugLevel>0</WasmDebugLevel>\n  <WasmNativeStrip>true</WasmNativeStrip>\n</PropertyGroup>

However, AOT increases build time and the size of the final file (but reduces the size of the loaded runtime). Configure WasmDebugLevel and WasmNativeStrip to remove debug information.

1.2. Lazy Loading and Assembly Splitting

For large applications, use Lazy Loading. You can load .NET libraries only on demand. In Blazor, this is done via LazyAssemblyLoader:

@inject LazyAssemblyLoader Loader\n\n@code {\n    private async Task LoadHeavyLibrary()\n    {\n        var assemblies = await Loader.LoadAssembliesAsync(new[] { "HeavyLibrary.dll" });\n        // Now the library is available\n    }\n}

This is critical for SEO and UX, as the Initial Load remains fast.

2. Deep-Level JavaScript Interop (JS Interop)

Advanced work with WebAssembly requires efficient data exchange between C# and JS. The standard IJSRuntime works through JSON serialization, which is slow for large amounts of data.

2.1. Direct Memory Work with Span and IntPtr

Use System.Runtime.InteropServices.JavaScript (available in .NET 7+). You can obtain pointers to JS arrays and work with them directly, avoiding copying.

using System.Runtime.InteropServices.JavaScript;\n\n// Exporting a C# function to JS\n[JSExport]\npublic static unsafe int ProcessData(int* dataPtr, int length)\n{\n    Span<byte> span = new Span<byte>(dataPtr, length);\n    // High-performance in-place processing\n    return span.Length;\n}\n\n// Importing a function from JS\n[JSImport("window.processResult", "MyModule")]\npublic static partial void ProcessResult(int result);

This approach allows processing images, audio, or large data arrays (e.g., from WebGL) without marshaling overhead.

2.2. Synchronous JS Interop

By default, calls from WASM to JS are asynchronous. For scenarios requiring synchronous behavior (e.g., in game loops), use [JSImport] with IsBlocking = true (available in .NET 8+). This allows blocking the WASM thread until a response from JS is received.

[JSImport("getTimestamp", "MyModule", IsBlocking = true)]\npublic