> 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.