Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries, for the same reason those languages have c extensions rather than extensions in other large runtime languages today.
There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, 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...
I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
A CDN may happen; there’s some details that make it tough. We’ll see.
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, 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.
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.
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.
(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)
In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers.
Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a way to host and cache such runtimes for multiple applications or websites.
Don't know how this will play with other languages.