One interesting thing about wasm is the difference between libraries and apps; Rust’s small binary size here can make it useful for this infrastructure work, but for languages that need to bring along the runtime, it’s much more complex. This is one reason why we’re pursuing stuff like wasm-pack.
I’m glad to see more and more languages compiling to wasm though! Exciting times.
I asked this same question[0]. Appears mono.js is 166kb in release mode, but it downloads/uses the DLLs directly as a system would, so those sizes are the same as they are for desktop apps (not sure off the top of my head what that is for ASP.Net stuff or the stdlib).
Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.
What? What kind of bubble are you working in?
In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...
The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size.
>the average web page size has upped to ~ 3MB these days...
This is not an excuse to make web pages' sizes even larger :).
Btw, I'm not against the idea of using a managed language that targets WebAssembly for front-end development. On the contrary, I'm very excited about Blazor and I'm following its development, and I would love to see similar frameworks for other languages such as Kotlin or Swift.
But while I think the size of a runtime won't be an issue for web applications that use such frameworks, I don't like the idea of shipping large runtimes with wasm packages that might be used with other languages.
Look at something like jQuery. Let's assume for the sake of discussion there are 50 versions of jQuery (that's a low estimate), and 6 majorly used CDNs. That's 300 distinct cachable items. Now add in that most people now use multiple devices, and that caches are generally completely full and evicting things constantly. The chances of having a specific version from a specific CDN on the specific device is actually pretty low.
Now multiply that whole thing by another 100 libraries that all want to be the next jQuery. It's just not going to happen.
And cross-domain or content based caching isn't a solution either as it's opens an extremely large security hole (basically being able to probe your cache checking if a specific hash or content exists in it).
I'd much rather spend our collective time improving dead code removal tools and optimizing tightly linked bundles of libraries to give each web application it's own customized, small, optimized, and easily cachable "bundle". It avoids the reliance on 3rd party CDNs, it gives control over caching behavior back to the original website, it improves security, and can be faster (both in download speed and runtime speed).