By A solo developer has shipped a C# compiler that produces WebAssembly binaries 355 times smaller than Microsoft’s optimized Blazor builds — and in one direct comparison, smaller than equivalent Rust output. NetWasm, released this week by GitHub user zion-sati, compiles C# and .NET CIL directly to WASI Preview 2 components without dragging the desktop CLR, Mono, or application DLLs into the output. The result: a hello-world that clocks in at 47 KB instead of 14 MB.
The Blazor Problem, in Numbers
Blazor WebAssembly is the official Microsoft path for shipping C# to the browser and to edge runtimes. In practice, that means shipping the .NET runtime with every deployment. Even with aggressive size optimizations applied — AOT compilation, managed trimming, IL stripping, invariant globalization, and size-focused native linking — Blazor .NET 10 produces 11.71 MB and Blazor .NET 11 RC1 reaches 14.58 MB for a program that prints the number 42. That is not a theoretical benchmark; that is the floor for a real Blazor app before it does anything useful.
For browser apps, a 14 MB initial payload hurts performance scores. For edge functions and WASI serverless workloads, it is a non-starter: platforms like Cloudflare Workers and Fastly Compute impose strict binary size limits and bill on cold-start time. Blazor simply cannot compete there, and Microsoft has not offered a solution.
How NetWasm Gets to 47 KB
NetWasm takes a different architectural premise: closed-world compilation. Rather than shipping a general-purpose runtime that handles any C# code at execution time, NetWasm’s compiler analyzes exactly what code your program calls and includes only that. No runtime reflection. No dynamic assembly loading. No dynamic keyword. The compiler builds a minimal platform from scratch — its own CoreLib, its own garbage collector, its own WASI bindings — tuned for the WebAssembly target rather than retrofitted from a desktop runtime.
Three GC strategies are available depending on your workload: Compact (default, size-optimized), NetWasmGC (higher throughput for long-running computation), and Bump (single-pass bounded jobs). Benchmarks on an Apple M1 Max show NetWasmGC completing allocation-heavy workloads in 43.9 ms versus 59.1 ms for Mono AOT — about 26% faster on that class of task, with larger gains on retained object graph and UI churn workloads.
On the Rust Comparison
The headline claim — that C# now beats Rust on Wasm binary size — is worth unpacking. NetWasm’s 47,895-byte output is 10.7% smaller than an equivalent Rust build at 53,635 bytes. The Hacker News thread that followed the project’s Show HN post immediately raised a valid concern: NetWasm’s output passes through Binaryen optimization as part of its standard toolchain, while the Rust binary did not. Rust can reach similarly tiny sizes with LTO, strip, and panic=abort — it just does not do so by default.
The honest read: with equivalent optimization passes applied, C# and Rust land in the same size range. That is genuinely impressive for a managed language with a garbage collector. But the more meaningful comparison is still with Blazor, where NetWasm wins by a factor of 355x — a gap no amount of methodological nuance closes.
What Works, What Does Not
NetWasm is pre-1.0 and deliberate about its constraints. The supported surface covers C# 15, generics with specialization, LINQ, async/await, JSON, HTTP, XML, Regex, dependency injection (reflection-free), and JavaScript module exports. TUnit and VSTest integration work for testing. That covers a realistic slice of backend and compute workloads.
What does not work: runtime reflection (System.Reflection), the dynamic keyword, managed threading, System.IO.File, raw sockets, and subprocess APIs. Existing NuGet packages that depend on any of those APIs will not compile. The project documentation is clear: if you find missing functionality, open an issue — the project is actively filling gaps on the path to 1.0.
Trying It
Setup is three commands:
dotnet new install NetWasm.Templates
dotnet new netwasm-app -n HelloNetWasm
dotnet publish -c ReleaseRequires .NET SDK 10.0.303 or newer. The output is a standalone WASI Preview 2 component — run it locally with Wasmtime, deploy it to Cloudflare Workers, or compose it with other Wasm components via WIT bindings.
The licensing split matters before you commit. The CoreLib and runtime are MIT-licensed with no restrictions. The compiler and tooling ship under the NetWasm Community License 1.0: free for individuals, open-source projects, education, and companies under 250 employees or $10M in annual revenue. Commercial teams above that threshold pay via GitHub Sponsors tiers starting at $149/month for five developers.
Worth Watching
NetWasm is not a Blazor replacement today. Missing threading, reflection, and broad NuGet ecosystem compatibility rule it out for most existing .NET web apps. But it is the first credible answer to a genuine problem: shipping C# to environments where Blazor’s binary size is a dealbreaker. WASI-based edge computing is one of the most active deployment targets of 2026, and having a .NET path into that ecosystem at native Wasm sizes is a meaningful development. Whether it turns into the official path, a community fork, or an influence on Microsoft’s own Blazor roadmap remains to be seen — but the benchmark numbers are hard to ignore.
