1. 27

  2. 6

    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

    1. 1

      Do browser’s need to include the vm’s or cant they just use the ones installed on your machine?

      1. 2

        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

        1. 1

          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

    2. 4

      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.

      1. 3

        The answer to “JavaScript isn’t as secure as I’d like it to be” sure as hell isn’t “replace it with a bunch of new, more general VMs”

        1. 3

          I think the subtlety is that Javascript’s shape makes people feel like they can “cheat” on the virtualization, and aren’t super careful. For example, Spectre is an issue because the JS ultimately is running within the browser process instead of in its own isolated environment.

          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.

          1. 3

            Indeed not, and the author says that in her post:

            But, it’s not JavaScript’s fault. I have my beef with Eich but I daresay things would be just as bad as they are now if Java had become the language of the web: behind every URL would lurk arbitrarily large applications with opaque rights to exploit your machinery, powered by advertising and malware. We can blame JS for being entrenched demoware but the ethics of the browser are distinct.

            She’s considering two things: one is that JavaScript isn’t great, and the other is that browser sandboxing isn’t great.