2 ms·
> WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript That's really not what I'm seeing, my WASM h
by flohofwoe 1y ago
> WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript
That's really not what I'm seeing, my WASM home computer emulators (written in plain C) run at about the same performance as their native counterparts (give or take 15%). Just don't switch between the JS and WASM side too often, and use WebGL or WebGPU for rendering (with proper batching).
...of course if you want to have a DOM-based UI framework in WASM, don't do that, but who would come up with such a stupid idea in the first place ;)
- skybrian 1y agoIt seems like Game UI is its own isolated world that doesn't tell you much about its suitability for regular apps. How often do games support or even need cut-and-paste?
- flohofwoe 1y agoIf you really need a DOM based UI I would write a hybrid application, do the UI completely on the JS side via the DOM, and the logic on the WASM side, with a minimal interface to communicate between the two and which doesn't need tons of roundtrips each frame. Games often need to do at least some DOM work though, like rendering a login dialog or integrating a 3rd party in-app-payment solution (or the obvious one: displaying ads). For this I would also do most work on the JS side. With Emscripten, such mixed JS/WASM apps are really not that hard, you can even embed JS code snippets right into the C/C++ code.