4 ms·

I'm almost to the point of being indifferent whether companies "destroy the web" through things like a browser monoculture. It would be a tragedy, but you can o

I'm almost to the point of being indifferent whether companies "destroy the web" through things like a browser monoculture. It would be a tragedy, but you can only ask people to deal with so much, and the web != the internet. We are in an age of webassembly in browsers. For all the complexity of the modern web, riddle me this: What is the difference between a website executing arbitrary web assembly code in the sandbox of the browser, and any TCP connection sending a program which is loaded in a sandbox and executing on the user's computer? The difference seems to me to be simply the fact that it is integrated into the web, web browsers, etc. If we are truly at the point where this is how we want to do things--like, we want to write web apps in Rust and compile for web assembly--The web is becoming less distinct and therefore less valuable as a paradigm. I'm not a user of any document-only web alternatives, but in this model, it would be pretty cool to see a re-separation into a web-of-linked-documents and network-of-sandboxed-remote-applications. Society wouldn't swallow such a thing easily, but if they push the web far enough into a proprietary hellscape, desirable services will likely start to emerge outside of it. All it takes is for those services to be attractive enough to start drawing disenfranchised stragglers, and the next thing you know, your mom is downloading recipes off the new not-web web without a care in the world.

pavlov 6y ago
WebAssembly is a red herring because anything useful that these applications do is enabled by the available APIs. A WAsm program can’t magically bypass the browser and access OS services directly. Everything still needs to go through web APIs, and then you realize that it doesn’t make much difference whether your program bitstream is delivered as minified JS or WAsm.
- anderspitman 6y ago
  I wonder what a fairly lightweight webapp standard wrapped around WASI might look like. Especially if it had a really nice high-level UI toolkit built it.
- bonestormii_ 6y ago
  Right, it necessarily affect much in terms of the way the program's functionality is written, but hardly irrelevant or a "red herring". The fact that any language can be compiled to a portable assembly language is important for the model we are discussing, because it isn't bound to local machine architecture. If a browser is simply a remote-program-sandbox, it is an important feature that remote programs are portable to the same degree web assembly is. Otherwise you'd have a remote app that people on ARM couldn't execute, and things of that nature. It also isn't strictly true what you say, that "anything useful" is achieved via APIs. There are a number of examples of native libraries being compiled to web assembly with varying degrees of success. Just because what you write is all API based doesn't make it universally true for all programs everywhere.
  - pavlov 6y ago
    > "There are a number of examples of native libraries being compiled to web assembly" Sure, but these are libraries. They don't provide any utility directly to an end-user. An application still has to wrap them into something that provides access through the Web APIs. Building native libraries for a web target was already possible before WAsm using Emscripten. Surely WAsm is still useful as it offers better performance and memory management, thus expanding the range of projects that can be ported this way, but it's more like an incremental evolution than a revolution.

pavlov 6y ago

WebAssembly is a red herring because anything useful that these applications do is enabled by the available APIs. A WAsm program can’t magically bypass the browser and access OS services directly. Everything still needs to go through web APIs, and then you realize that it doesn’t make much difference whether your program bitstream is delivered as minified JS or WAsm.

anderspitman 6y ago
I wonder what a fairly lightweight webapp standard wrapped around WASI might look like. Especially if it had a really nice high-level UI toolkit built it.
bonestormii_ 6y ago
Right, it necessarily affect much in terms of the way the program's functionality is written, but hardly irrelevant or a "red herring". The fact that any language can be compiled to a portable assembly language is important for the model we are discussing, because it isn't bound to local machine architecture. If a browser is simply a remote-program-sandbox, it is an important feature that remote programs are portable to the same degree web assembly is. Otherwise you'd have a remote app that people on ARM couldn't execute, and things of that nature. It also isn't strictly true what you say, that "anything useful" is achieved via APIs. There are a number of examples of native libraries being compiled to web assembly with varying degrees of success. Just because what you write is all API based doesn't make it universally true for all programs everywhere.
- pavlov 6y ago
  > "There are a number of examples of native libraries being compiled to web assembly" Sure, but these are libraries. They don't provide any utility directly to an end-user. An application still has to wrap them into something that provides access through the Web APIs. Building native libraries for a web target was already possible before WAsm using Emscripten. Surely WAsm is still useful as it offers better performance and memory management, thus expanding the range of projects that can be ported this way, but it's more like an incremental evolution than a revolution.