5 ms·

I've been struggling to understand how WebAssembly will change things on the web. Will you be able to compile an arbitrary C/C++ binary to run on a browser? Wil

by copperx 10y ago

I've been struggling to understand how WebAssembly will change things on the web. Will you be able to compile an arbitrary C/C++ binary to run on a browser? Will syscalls be emulated? What about the filesystem? It looks like to get such a thing working we would need an OS running on top of JS. But maybe I'm missing something.

colordrops 10y ago
There is clearly some sort of mapping available to a JavaScript FFI for doing I/O, as both the Unreal engine and Unity have been ported to WebAssembly. If you can run a video game engine in the browser you can run anything. I believe there are proposals in place as well to add opcodes to directly interface with browser capabilities rather than going through a JS FFI.
- leeoniya 10y ago
  > If you can run a video game engine in the browser you can run anything no
  - colordrops 10y ago
    enlighten us
    - leeoniya 10y ago
      ok, assuming your request is not sarcastic: - operating systems - hardware drivers - a networking stack - trading algorithms - fighter jet firmware - ultra low latency DSP - processing data from LHC collisions or imaging satellites. - etc - etc - etc just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything.
      - colordrops 10y ago
        The implication was applications. But even then, everything on your list is emphatically not true: - operating systems Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten. - hardware drivers Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs. - a networking stack Yes you can. - trading algorithms Why not? - fighter jet firmware It's not a fighter jet, but the SpaceX Dragon 2 space capsule's UI is built using Chromium. - ultra low latency DSP Why not? - processing data from LHC collisions or imaging satellites. Why not?
        leeoniya 10y ago
        wish i had more time for the multitude of your generic "why not?"s, but i don't :( any language (high or low level) that allows you to write and execute deterministic assembly or machine code can be used to implement whatever you want. whether WASM ever reaches this type of broad security-sensitive wild-west remains to be seen, but my money is on "never". wasm will certainly expand into additional areas, but they will all be security-gated and will not have unfettered, raw access to all hardware (even with some additional user-grokkable permission model), because it has to run on the web: "W"asm
        Dylan16807 10y ago
        That's entirely addresed by "The implication was applications." Nobody was trying to make a claim about web assembly drivers. Just applications.
        johncolanduoni 10y ago
        You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist. Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm. The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.
linclark 10y ago
A tool called Emscripten provides a runtime environment. You can include things from that, like a virtual filesystem. That said, a lot of WebAssembly code doesn't have a dependency on file APIs. For example, you can check out the web-dsp project: https://github.com/shamadee/web-dsp https://github.com/shamadee/web-dsp If you're looking for an intro, I wrote a series of posts on WebAssembly (there are 5 links at the bottom of this intro): https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...
losteric 10y ago
> It looks like to get such a thing working we would need an OS running on top of JS. But maybe I'm missing something. You're not missing anything, that's exactly what's happening. WebGL/VR, WebCL, WebRTC, Filesystem API... the browser is becoming a simple feature-rich client OS for the cloud, and WebAssembly is the machine language.

by copperx 10y ago

colordrops 10y ago

There is clearly some sort of mapping available to a JavaScript FFI for doing I/O, as both the Unreal engine and Unity have been ported to WebAssembly. If you can run a video game engine in the browser you can run anything. I believe there are proposals in place as well to add opcodes to directly interface with browser capabilities rather than going through a JS FFI.

leeoniya 10y ago
> If you can run a video game engine in the browser you can run anything no
- colordrops 10y ago
  enlighten us
  - leeoniya 10y ago
    ok, assuming your request is not sarcastic: - operating systems - hardware drivers - a networking stack - trading algorithms - fighter jet firmware - ultra low latency DSP - processing data from LHC collisions or imaging satellites. - etc - etc - etc just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything.
    - colordrops 10y ago
      The implication was applications. But even then, everything on your list is emphatically not true: - operating systems Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten. - hardware drivers Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs. - a networking stack Yes you can. - trading algorithms Why not? - fighter jet firmware It's not a fighter jet, but the SpaceX Dragon 2 space capsule's UI is built using Chromium. - ultra low latency DSP Why not? - processing data from LHC collisions or imaging satellites. Why not?
      - leeoniya 10y ago
        wish i had more time for the multitude of your generic "why not?"s, but i don't :( any language (high or low level) that allows you to write and execute deterministic assembly or machine code can be used to implement whatever you want. whether WASM ever reaches this type of broad security-sensitive wild-west remains to be seen, but my money is on "never". wasm will certainly expand into additional areas, but they will all be security-gated and will not have unfettered, raw access to all hardware (even with some additional user-grokkable permission model), because it has to run on the web: "W"asm
        Dylan16807 10y ago
        That's entirely addresed by "The implication was applications." Nobody was trying to make a claim about web assembly drivers. Just applications.
      - johncolanduoni 10y ago
        You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist. Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm. The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.

linclark 10y ago

A tool called Emscripten provides a runtime environment. You can include things from that, like a virtual filesystem. That said, a lot of WebAssembly code doesn't have a dependency on file APIs. For example, you can check out the web-dsp project: https://github.com/shamadee/web-dsp https://github.com/shamadee/web-dsp If you're looking for an intro, I wrote a series of posts on WebAssembly (there are 5 links at the bottom of this intro): https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...

losteric 10y ago

> It looks like to get such a thing working we would need an OS running on top of JS. But maybe I'm missing something. You're not missing anything, that's exactly what's happening. WebGL/VR, WebCL, WebRTC, Filesystem API... the browser is becoming a simple feature-rich client OS for the cloud, and WebAssembly is the machine language.