This looks cool, even though I have never used .NET. Rust seems like something that a lot of people are using to compile into web assembly. It would be fascinating to see what alternatives there are here to those two and how they all compare. Go?
While I had the impression that GC support means the will expose the JavaScript engine's GC to be used by other languages and I don't know if it would work for all, is the GC really such a big chunk of these runtimes?
One of the things that surprised me is that Blazor doesn't compile the app code to WASM; it actually runs a WASM build of the CLR in the browser, which is used to interpret regular .NET DLLs sent from the server.
I like the _idea_ of it, but watching one of the Blazor sample sites pull down 1.65MB of mono.wasm_plus_ nearly two megabytes of DLLs (from mscorlib.dll, System.Core.dll) is... sobering.
For this to be practical, it needs a lot of trimming down, and I'm not sure how viable it is to do AOT and go through all the assemblies to do branch pruning before generating a cut-down WASM.
I do see a lot of appeal for enterprise scenarios and code reuse, and I guess there is a lot of potential there.
Companies will want to use their existing code-bases to make better SaaS offerings, Unity and Epic are already leveraging their C++ and C# engines.
I don't think too many people will start throwing new projects in the Web that are based on C#, Java or Go, 99% will be existing projects.
Probably Rust will make this race. It's more modern, no GC, almost C like performance and pushed by Mozilla who is THE company with the most Web know-how.
First it will eat the libraries and if they can flatten out the learning curve a bit, probably even the rest of the stack.
Since I presume these asm-compiled .NET BCL binaries are largely immutable, I think they can be cached aggressively. This means that the initial cost of downloading them may be high, but it browsers would support some kind of hashed asm library caching, this cost would be mostly one-off actions.
We're also going to have widespread gigabit fiber and 5G soon, probably prior to significant adoption of technologies like this. So even if there is a period of time where these optimizations don't exist yet, rapidly improving internet speeds will help mitigate some of it as well.
I am sure that the .NET Core team is not going to rest on their laurels with this technology; usually they are pretty good at optimizing stuff. Right now, it's only a proof of concept that's still in beta.
CoreRT is investigating wasm as a target. Discussion here about compatibility with blazor. In theory it should spit out much smaller binaries/bundles
https://github.com/dotnet/corert/issues/4659
19 comments
[ 2.9 ms ] story [ 49.6 ms ] threadI also have my doubts but more regards performance of a shared WebAssembly GC in regards to different runtimes.
https://radiopublic.com/hanselminutes-fresh-talk-and-tec-Wzn...
One of the things that surprised me is that Blazor doesn't compile the app code to WASM; it actually runs a WASM build of the CLR in the browser, which is used to interpret regular .NET DLLs sent from the server.
In the future, .NET Native or CoreRT will target WebAssembly as well, the work for it is already ongoing.
(Just go over to https://blazor.net/community.html, pick a demo and fire up your web inspector of choice)
For this to be practical, it needs a lot of trimming down, and I'm not sure how viable it is to do AOT and go through all the assemblies to do branch pruning before generating a cut-down WASM.
I do see a lot of appeal for enterprise scenarios and code reuse, and I guess there is a lot of potential there.
Companies will want to use their existing code-bases to make better SaaS offerings, Unity and Epic are already leveraging their C++ and C# engines.
I don't think too many people will start throwing new projects in the Web that are based on C#, Java or Go, 99% will be existing projects.
Probably Rust will make this race. It's more modern, no GC, almost C like performance and pushed by Mozilla who is THE company with the most Web know-how.
First it will eat the libraries and if they can flatten out the learning curve a bit, probably even the rest of the stack.
I am sure that the .NET Core team is not going to rest on their laurels with this technology; usually they are pretty good at optimizing stuff. Right now, it's only a proof of concept that's still in beta.