Web applications nowadays depend on hundreds of dependencies. If each one of these dependencies were to have a size of 60kb or more that would be very bad.
>Not only will most frameworks and standard JS libs dwarf this
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.
The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger...
This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used side-by-side with other languages.
I think what he means is that C# apps would have a smaller size if AOT compiled to wasm instead of shipping the mono runtime with .NET assemblies. (sorry for my English)