>I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libr

>I am not talking so much about porting an entire language run-time for a language with a very system dependent run-time, and I am not talking about useful libraries of these languages, I am talking about garbage collection. I'm talking about the former as pretty much the entirety of my previous comment tried to convey. >I also don't see the advantage of WebAssembly as a compiler target in general. The advantage is it would be a single target. >So it's impractical in some cases because of large binaries, not for any of the reasons you've pointed out so far. Giving WebAssembly programs a way to integrate with the VM GC will change this how, exactly? It's impractical primarily because it's not production-ready. In the interests of pedantry however, reliance on a VM GC would likely result in a somewhat smaller binary size. >In Blazor's case the large file size can likely be attributed to things not strictly related to the run-time, like the core libraries. Per its readme: "This is because Mono on WASM doesn't yet have any IL stripping or minification, and bundles a large runtime that includes many desktop-related features that are irrelevant on the web." >What is general web use, and how does it relate to WebAssembly? Most people use the internet to visit websites. Most major websites optimize their page loads as much as possible to fit as many ads in as they can without completely tanking the user experience. Using the previous example, a 4MB binary doesn't fit that use case. It would be more the realm of specialized applications. >What are the alternatives? Javascript ecosystem or production-ready compiled languages that target wasm.