Hacker News Reader

Comment by ampdepolymerase | Hacker News Reader

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

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

(Also implemented a WACC Viewer in Rust: 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.

Can you link to some of your applications?

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?

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

In a browser environment, sure because browsers need to sandbox webpages. But WASM runs on different environments too.

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.

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.

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

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.

As secure as an OS process.

There are proofs of concept using shaders for security attacks.

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

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?

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)

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.

Reply on news.ycombinator.com