4 ms·

You still need a browser if you want to do anything GUI related.

edgyquant 5y ago
You it be faster though? E.g. as a replacement for electron (please note I’ve never worked with electron so I’m using anecdata)
- imbnwa 5y ago
  If I understand correctly, the consequence is that, Electron being a wrapper around a fully capable browser engine, Electron users are free to use WASM modules so long as they expose a JS interface to interact with Electron's API where neccessary but until WASM gets DOM bindings I presume that Electron itself won't use WASM to implement internal behavior.
kitsunesoba 5y ago
Would it not be adequate to supply a minimal implementation of canvas and develop with a UI framework that draws to canvas? Or perhaps something like React Native, with WASM standing in for the JS runtime?
SahAssar 5y ago
Why? Other languages running in similar environments like Lua/Java don't need a browser. WASM does not need to run within a browser, and there are a couple of runtimes that run it outside of a browser, in that case why wouldn't something like SDL be able to be used?
- flohofwoe 5y ago
  The most important feature of WASM is that it provides a secure sandbox, and all APIs that talk to the underlying host platforms must be designed with security in mind (see all the considerations that went into WebGL vs vanilla OpenGL).
  - SahAssar 5y ago
    In a browser environment, sure because browsers need to sandbox webpages. But WASM runs on different environments too.
    - flohofwoe 5y ago
      It's also important outside the browser, WASM could be the solution for running untrusted code without a walled-garden app distribution model, but only if the sandbox actually works.
      - pjmlp 5y ago
        As long as the internal memory doesn't get corrupted due to lack of bounds checking inside linear memory internal accesses. Corruption that can then be used to subvert the behaviour of functions being called.
        flohofwoe 5y ago
        That's a language-level problem, e.g. "just use Rust" if you're concerned about "sandbox-internal" memory corruption (and that this internal corruption can't be used to alter the behaviour of called host platform functions is why APIs must be designed with security in mind - WASM running in browsers has the same problem, that's why WebGL does additional validation compared to native GL implementations).
        pjmlp 5y ago
        Just use language X only works when not relying on 3rd party WASM libraries, also I bet emscripten sees much more use on the wild than Rust. WebGL additional validation is so good that the only way to work around exploits is to blacklist user's hardware, OS and GPU drivers. Thus rendering those nice 60 FPS scenes into a single digit FPS caused by software emulation. Security would be so much better if liability was already thing across the industry, and not only on high integrity systems.
  - 5y ago
flohofwoe 5y ago
WASI could be extended by "media APIs" to communicate with a host platform window system, rendering- and audio-API. The only question is "where to stop?", because at the end of that road lies a complete browser runtime (I still think it makes sense to extend WASI with a small number of media APIs though).
follower 5y ago
While a "host" application (for the WASM runtime used) is required to enable access to graphical output (or user input) it doesn't have to be a browser. At the (almost) most basic level a chunk of memory can be used as a framebuffer--the host application would read the pixel data which the WASM bytecode wrote and then write it to the host display via OS-level routines. There are some plans/experiments at making a framebuffer "device" available as part of WASI. I've written a couple of graphical WASM host applications that aren't browsers (and which don't use memory for pixel data transfer just integer values returned from a function): The "WebAssembly Calling Card (WACC) Viewer" is implemented via the Godot game engine and an addon that integrates the Wasmtime WASM runtime with the engine: https://wacc.rancidbacon.com https://wacc.rancidbacon.com (Also implemented a WACC Viewer in Rust: https://gitlab.com/RancidBacon/rusty-wacc-viewer https://gitlab.com/RancidBacon/rusty-wacc-viewer) WACC specifies how to transform three integer values (returned from a function in a WASM module) into a coloured triangle in order to render it on screen. Another "host application" I implemented was a libretro compatible plugin that loads a WASM module and then feeds the module with input from libretro & retrieves framebuffer pixel data (one pixel at a time :D ) via a WASM function call & writes it to the libretro framebuffer for display.
- ampdepolymerase 5y ago
  Can you link to some of your applications?

You it be faster though? E.g. as a replacement for electron (please note I’ve never worked with electron so I’m using anecdata)

imbnwa 5y ago
If I understand correctly, the consequence is that, Electron being a wrapper around a fully capable browser engine, Electron users are free to use WASM modules so long as they expose a JS interface to interact with Electron's API where neccessary but until WASM gets DOM bindings I presume that Electron itself won't use WASM to implement internal behavior.

kitsunesoba 5y ago

Would it not be adequate to supply a minimal implementation of canvas and develop with a UI framework that draws to canvas? Or perhaps something like React Native, with WASM standing in for the JS runtime?

SahAssar 5y ago

Why? Other languages running in similar environments like Lua/Java don't need a browser. WASM does not need to run within a browser, and there are a couple of runtimes that run it outside of a browser, in that case why wouldn't something like SDL be able to be used?

flohofwoe 5y ago
The most important feature of WASM is that it provides a secure sandbox, and all APIs that talk to the underlying host platforms must be designed with security in mind (see all the considerations that went into WebGL vs vanilla OpenGL).
- SahAssar 5y ago
  In a browser environment, sure because browsers need to sandbox webpages. But WASM runs on different environments too.
  - flohofwoe 5y ago
    It's also important outside the browser, WASM could be the solution for running untrusted code without a walled-garden app distribution model, but only if the sandbox actually works.
    - pjmlp 5y ago
      As long as the internal memory doesn't get corrupted due to lack of bounds checking inside linear memory internal accesses. Corruption that can then be used to subvert the behaviour of functions being called.
      - flohofwoe 5y ago
        That's a language-level problem, e.g. "just use Rust" if you're concerned about "sandbox-internal" memory corruption (and that this internal corruption can't be used to alter the behaviour of called host platform functions is why APIs must be designed with security in mind - WASM running in browsers has the same problem, that's why WebGL does additional validation compared to native GL implementations).
        pjmlp 5y ago
        Just use language X only works when not relying on 3rd party WASM libraries, also I bet emscripten sees much more use on the wild than Rust. WebGL additional validation is so good that the only way to work around exploits is to blacklist user's hardware, OS and GPU drivers. Thus rendering those nice 60 FPS scenes into a single digit FPS caused by software emulation. Security would be so much better if liability was already thing across the industry, and not only on high integrity systems.
- 5y ago

flohofwoe 5y ago

WASI could be extended by "media APIs" to communicate with a host platform window system, rendering- and audio-API. The only question is "where to stop?", because at the end of that road lies a complete browser runtime (I still think it makes sense to extend WASI with a small number of media APIs though).

follower 5y ago

While a "host" application (for the WASM runtime used) is required to enable access to graphical output (or user input) it doesn't have to be a browser. At the (almost) most basic level a chunk of memory can be used as a framebuffer--the host application would read the pixel data which the WASM bytecode wrote and then write it to the host display via OS-level routines. There are some plans/experiments at making a framebuffer "device" available as part of WASI. I've written a couple of graphical WASM host applications that aren't browsers (and which don't use memory for pixel data transfer just integer values returned from a function): The "WebAssembly Calling Card (WACC) Viewer" is implemented via the Godot game engine and an addon that integrates the Wasmtime WASM runtime with the engine: https://wacc.rancidbacon.com https://wacc.rancidbacon.com (Also implemented a WACC Viewer in Rust: https://gitlab.com/RancidBacon/rusty-wacc-viewer https://gitlab.com/RancidBacon/rusty-wacc-viewer) WACC specifies how to transform three integer values (returned from a function in a WASM module) into a coloured triangle in order to render it on screen. Another "host application" I implemented was a libretro compatible plugin that loads a WASM module and then feeds the module with input from libretro & retrieves framebuffer pixel data (one pixel at a time :D ) via a WASM function call & writes it to the libretro framebuffer for display.

ampdepolymerase 5y ago
Can you link to some of your applications?