6 ms·
To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started. This required only a hand
by TomasSedovic 9y ago
To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started.
This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game.
Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games.
But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you:
https://github.com/koute/stdweb https://github.com/koute/stdweb
- seanmcdirmid 9y agoDoes WASM provide a canvas API at least (i.e. something more advanced than pushing pixels to a buffer)?
- steveklabnik 9y agoNope, you call into JS for that as well. Canvas, WebGL, whatever.
- tyingq 9y agoThe bridge is currently VERY slow though. Like 10x slower than doing it in JS, sometimes worse.
- zaarn 9y agoThen applications in WASM will have to reduce the number of these calls until it gets native. This can be easily achieved by buffering calls to the DOM and merging batches of actions together (you could probably even divide DOM actions into priority queues to improve reaction time at expense of throughput in less important UI elements)
- imtringued 9y agoI'm wondering if it would make sense to have a virtual DOM inspired by react. This would be faster than direct DOM access via a bridge.
- zaarn 9y agoA vastly simplified DOM if anything. I imagine each language will use native objects, like how .NET did it for a while. But I don't think languages will interact with the DOM extensively once it has been properly abstracted. One major difficulty would be to have it available quickly so a page refresh doesn't take until the WASM binary has sorted out it's internal state.