> 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.
Very cool. Congratulations.
> 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?
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.
Good idea! Any suggestions?