This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.

No, parent clearly wrote that Webassembly is limited to Rust and C due to having no Garbage Collection. Which, as I demonstrated, is just wrong.

That's only a problem for more traditional websites. For applications 1MB is just not an issue.

I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?

As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick.

A CDN may happen; there’s some details that make it tough. We’ll see.

npm is already that package manager :)

>npm is already that package manager :)

No, we should be working to replace NPM and the bad influence of the javascript community, not double down on their ubiquity. We should be able to do a lot better than sticking with NPM and wrapping everything in Chromium.

No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks...

No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications.

In the simplest form Google or Python.org could serve these files on a CDN. In a more complicated form you could run an application on a range of Python versions, and only download updates when you want and need them.

Ah, yeah. We’ll see if it happens.

Right but those languages compile in their own garbage collector. That's not the same as a VM provided garbage collector, and furthermore, the GC used in browsers also manages DOM allocations, and thus directly interfacing the DOM without JS is impossible until the VM GC is implemented.