> Webassembly is mainly just for C and Rust

That's absolutely incorrect. Go and .NET can target WASM for quite a while now.

Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png

Code here: https://github.com/aspnet/samples/tree/master/samples/aspnet...

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.

The "problem" with integrating with the host gc is that it means language who have subtly different approaches to garbage collection can't trust compiled code behavior to be identical in the browser.

This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages that want to include one.

It is (probably) better for individual languages to write their own, even if that increases binary sizes.

Of course, if you have a bunch of languages that compile to JavaScript, they all share the same low-level object layout and garbage collector. This VM has a lot of momentum.

The problem is that languages that are genuinely different from JavaScript (such as Dart and Go via gopher) have their own static linkers that generate a big blob of JavaScript. To really do interop right, you need to share a common linker and data format for public API calls. And to make this efficient, it needs to handle inlining and tree-shaking. At that point you might as well use JavaScript or a light overlay language like TypeScript.

With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.

It would be neat if they could be cached as language-specific GCs, rather than having to be bundled individually with each application.

This is something that interests me as well. If you have separate WASM binaries, right now they have to be on separate threads. For many languages, that may not matter, but it would be interesting to see if there was some way to split up a WASM binary on the same thread and apply caching to some of it.

Note that’s more “integrate with a host’s GC” than it is “add a GC.” A subtle but important difference.

That "integration with the browser’s garbage collector" feature in the webassembly roadmap doesn't mean the inclusion of a GC - it means there will be a mechanism by which a WASM-implemented GC can cooperate with the browser GC.

(There seem to be additional long term ideas int he wasm design repos for adding more GC support, but they seem vague at this point and it's not clear how interested browser vendors or language implementors are)