I’ve been building NetWasm: an independent .NET compiler, CoreLib and runtime designed specifically for WebAssembly. It compiles Roslyn-generated CIL into standalone core WASM or WASI Preview 2 components - without shipping CoreCLR or Mono.
A clean Release application containing Console.WriteLine(42) produces 82.5 KB of final WASM with WASI p2, including the runtime and precise garbage collector.
The playground runs fully on the browser without a backend / cloud server compiling your code - it's all WASM! Locally, you use dotnet new, dotnet build, dotnet test, etc like you would normally. You can run the self-contained .wasm output with wasmtime, fully portable.
It's CIL (used to be called MSIL - it's the dotnet bytecode in other words) to WASM compiler. But more than that it's intentionally not using Microsoft's Corelib. We avoid reflection, typename with full namespace strings etc where the resulting .wasm can end up bloated. The goal is to have C# (and later .NET in general - thus F# and VB.NET) be on equal footing as Kotlin/WASM. Note that Kotlin/WASM uses WasmGC, NetWasm uses BoehmGC in precise mode. NetWasm makes Wasm a first class target.
Why NetWasm?
I fell in love with C# in 2006 and have OSS attempts at building C#-like syntax using C++ template metaprogramming with BoehmGC a long time ago because I didn't like the idea of having a runtime pre-installed. This idea was revitalized when I tried to migrate my web UI framework FUI-RS to C# - the resulting smoke test was already a minimum of 1 MB Brotli compressed running in interpreter mode! FUI-RS (Rust) had it at under 50 KB uncompressed. What already works?
C# 15, precise GC, finalization, exceptions, generics, virtual/interface dispatch, LINQ, tasks / value tasks (thus async-await), JSON, dependency injection, regex, XML, HTTP, WIT/WASI and TUnit (a modern source generated unit testing framework) etc.
What's left to do?
There's a roadmap to v1.0 on the repo's README - tl;dr there's a lot to do before we can get there, e.g. Expression trees, faster dev loops, threading, web workers, interop via libimport and globalization (opt-in just like NetWasm's implementation of timezone info).
NuGet packages should be able to multitarget to support NetWasm as well as the full .NET as long as there's no reflection / typename involved.
Licence: Runtime, CoreLib, templates and libraries: MIT
Compiler and tooling: NetWasm Community License
Note that NetWasm is pre-1.0 (currently v0.5) and evolving rapidly, so I'd appreciate any technical feedbacks from the community if you'd like to help me shape this project. Particularly, real WASI use cases people want supported, NuGet packages to multitarget (or even better if you're one of the popular open source packages and would like to start multitargeting).
There's a roadmap to v1.0 on the repo's README - tl;dr there's a lot to do before we can get there, e.g. Expression trees, faster dev loops, threading, web workers, interop via libimport and globalization (opt-in just like NetWasm's implementation of timezone info).
Is your mental model to try catch up and stay as close to latest C# language features? Or do you think it would be more strategic to only support a (very strong and broad) subset of C# that harmonizes well with in-browser WASM? I can understand if you don't want to limit this to browser-based applications, in which case you want much broader functionality such as for server implementations.
I'm specifically wondering, since Microsoft provides two official ways to compile C# to WASM. That also makes me wonder, why should someone pick NetWasm over MSFT tooling? Is it primarily if you want to use C#/.Net but not tied to Microsoft? Or are there technical reasons too?
Microsoft's support for WASI has been pretty slow. Wasm isn't just for the browser - it came from there but with WASI, Wasm has the opportunity to run just about anywhere, even more portable than .NET Core.
MSFT's interest in making a wasm profile has been somewhat lacking and I understand the reason - the size I managed to achieve would've been impossible if I went with the full BCL / CoreLib. In particular, I had to cut reflection and typenames, keeping only thin RTTI.
So yes to staying as close to the latest C# language features but also deliberately not supporting features that bloat the resulting wasm if there's better and more modern alternatives such as source generation in place of reflection.
Sweet. One interesting thing you could consider is a gallery of a limited set of strategically chosen open-source C# projects compiled to WASM to show the range of NetWasm.
A clean Release application containing Console.WriteLine(42) produces 82.5 KB of final WASM with WASI p2, including the runtime and precise garbage collector.
Website: https://www.netwasm.com/ Playground: https://playground.netwasm.com/
The playground runs fully on the browser without a backend / cloud server compiling your code - it's all WASM! Locally, you use dotnet new, dotnet build, dotnet test, etc like you would normally. You can run the self-contained .wasm output with wasmtime, fully portable.
GitHub repos: https://github.com/zion-sati/NetWasm https://github.com/zion-sati/NetWasm.Libraries
What is it?
It's CIL (used to be called MSIL - it's the dotnet bytecode in other words) to WASM compiler. But more than that it's intentionally not using Microsoft's Corelib. We avoid reflection, typename with full namespace strings etc where the resulting .wasm can end up bloated. The goal is to have C# (and later .NET in general - thus F# and VB.NET) be on equal footing as Kotlin/WASM. Note that Kotlin/WASM uses WasmGC, NetWasm uses BoehmGC in precise mode. NetWasm makes Wasm a first class target.
Why NetWasm?
I fell in love with C# in 2006 and have OSS attempts at building C#-like syntax using C++ template metaprogramming with BoehmGC a long time ago because I didn't like the idea of having a runtime pre-installed. This idea was revitalized when I tried to migrate my web UI framework FUI-RS to C# - the resulting smoke test was already a minimum of 1 MB Brotli compressed running in interpreter mode! FUI-RS (Rust) had it at under 50 KB uncompressed. What already works?
C# 15, precise GC, finalization, exceptions, generics, virtual/interface dispatch, LINQ, tasks / value tasks (thus async-await), JSON, dependency injection, regex, XML, HTTP, WIT/WASI and TUnit (a modern source generated unit testing framework) etc.
What's left to do?
There's a roadmap to v1.0 on the repo's README - tl;dr there's a lot to do before we can get there, e.g. Expression trees, faster dev loops, threading, web workers, interop via libimport and globalization (opt-in just like NetWasm's implementation of timezone info).
NuGet packages should be able to multitarget to support NetWasm as well as the full .NET as long as there's no reflection / typename involved.
Licence: Runtime, CoreLib, templates and libraries: MIT Compiler and tooling: NetWasm Community License
Note that NetWasm is pre-1.0 (currently v0.5) and evolving rapidly, so I'd appreciate any technical feedbacks from the community if you'd like to help me shape this project. Particularly, real WASI use cases people want supported, NuGet packages to multitarget (or even better if you're one of the popular open source packages and would like to start multitargeting).
Very cool. Congratulations.
Is your mental model to try catch up and stay as close to latest C# language features? Or do you think it would be more strategic to only support a (very strong and broad) subset of C# that harmonizes well with in-browser WASM? I can understand if you don't want to limit this to browser-based applications, in which case you want much broader functionality such as for server implementations.
I'm specifically wondering, since Microsoft provides two official ways to compile C# to WASM. That also makes me wonder, why should someone pick NetWasm over MSFT tooling? Is it primarily if you want to use C#/.Net but not tied to Microsoft? Or are there technical reasons too?
Thank you :)
Microsoft's support for WASI has been pretty slow. Wasm isn't just for the browser - it came from there but with WASI, Wasm has the opportunity to run just about anywhere, even more portable than .NET Core.
MSFT's interest in making a wasm profile has been somewhat lacking and I understand the reason - the size I managed to achieve would've been impossible if I went with the full BCL / CoreLib. In particular, I had to cut reflection and typenames, keeping only thin RTTI.
So yes to staying as close to the latest C# language features but also deliberately not supporting features that bloat the resulting wasm if there's better and more modern alternatives such as source generation in place of reflection.
Sweet. One interesting thing you could consider is a gallery of a limited set of strategically chosen open-source C# projects compiled to WASM to show the range of NetWasm.