Blazor Toast Notifications Using Only C#, HTML and CSS | Hacker News Reader

Blazor Toast Notifications Using Only C#, HTML and CSS

codedaze.io

57 pointscsainty19 comments

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.

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

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

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.

If they load these DLLs on demand, why not?

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.

That's, like, an entire half a second man! /s

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.

Still way less of the image and auto play videos advertising junk many websites download.

The Hanselminutes podcast featured a really interesting episode on Blazor earlier this year:

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.

For the time being.

In the future, .NET Native or CoreRT will target WebAssembly as well, the work for it is already ongoing.

It reminds me of asp net webforms.

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?

I'm especially interested in the size of C#, Java and Go solutions that compile to WASM.

It sends a wasm build of the entire CLR and the same executables you can run natively, so it's gonna be big.

They're going to be large for a while. In time they'll shrink down to something more reasonable.

Specially since both support linkers and future WebAssembly improvements will reduce the runtime requirements.

IIRC, Rust is often chosen because you don't have to embed a garbage collector with your code. That's not the case with Go (or C#)

WebAssembly roadmap plans to add GC support, so that is only an interim issue.

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?

.NET has the concept of pluggable GC since last CoreCLR release. I highly suspect that other runtimes will have the same.

I also have my doubts but more regards performance of a shared WebAssembly GC in regards to different runtimes.

Reply on news.ycombinator.com