4 ms·

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 bro

by 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.

by pavlov 6y ago

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.