Good read. But isn’t the Multi-language point exactly what WebAsm is trying to address? In WebAsm we are able to target different languages to one lower level language browsers understand, but seems like author wants the browser to understand how to work with them natively (meaning supporting other languages and have their VMs, runtimes etc). Won’t that make browser bigger OS-like monsters, memory hogs etc? I think this is a bit of an overwhelming idea for a browser. Web Assembly is a good solution for what it does
Do browser’s need to include the vm’s or cant they just use the ones installed on your machine?
Even if they use the ones on my machine that’ll mean browser will require me to have them installed, as prerequisites, or try to install them itself, and use them on runtime. This is way too much for what a browser needs to do, IMHO. Just go for Wasm to accomplish the same without having to support tens of languages on the browser, and also, you need to react to render “on your own native language”. They’ll have to convert render calls to canvas, WebGL, DOM, whatever. You can’t achieve that by just using the VMs installed
Thats definitely a problem. But what about sandboxed statically compiled applications? The browser wouldnt need to do any rendering itself, but you are sacrificing bandwith and non compiled languages
IPFS plugins ? I’ll have to check that out. But I really like the idea of multi-protocol browsers, Or at least separate the html / css / js viewing part of it from the ressource fetching part ( So we can compose other ressource fetchers with it)
Edit: https://github.com/ipfs-shipyard/ipfs-companion it requires firefox 57 though, and I’ve yet to switch my openbsd laptop to current.
By going towards more general VMs you acknowledge “hey, anything can happen in this box, but it better stay there”. The mentality defaults to “anything can happen”, and you need explicit ways out.
Indeed not, and the author says that in her post: