04/28/2019, 8:57 AM
I'm considering implementing a WebAssembly App as 'just another Client', following the MVP pattern, and using Kotlin/wasm32, writing a View layer using the HTML DOM klib. One obvious problem I'm wondering about when taking this approach, is the browser back button: if writing a stateful WebAssembly 'Application', then the browser back-button would, on the face of it, be like an 'immediate quit', losing all the App state and potentially ruining the UX. Is there a way to veto or intercept the back-button? (I'm an experienced mobile dev. but a dummy when it comes to front-end web... hoping to crack that with wasm) Normally I'd be against taking control of the back-button but this seems like a valid use case (i.e. intercept the 'back's for your Apps own purposes, until it's at 'root' and the next 'back' is then passsed to the browser for an actual 'back').


04/28/2019, 10:59 PM
Kotlin's WASM support currently isn't at a level where it is ready for experimentation (aka developing programs for trying stuff out). All the Kotlin WASM libraries that exist are black boxes (source code isn't available) so there is no way to troubleshoot problems, and see what is going on in behind the scenes.
🤔 1


04/29/2019, 12:46 AM
Fair warning, @napperley 👍 Looking forward to seeing this avenue mature though, feels most promising.