Wasm code splitting

[ufoscout]

Javascript based SPA frameworks allow lazy-loading of modules to reduce the size of the application main bundle. Is this something that can be achieved with wasm? Would it ever be possible to support this feature in perseus?

[phaleth]

I guess right now I can only answer the WebAssembly side of things.

The WebAssembly and JavaScript browser interoperability allows for code splitting via WebAssembly's tables and carefully predefined lazy loading of WASM modules with JavaScript's fetch API. The concept of tables in WebAssembly isn't very dynamic as table entries cannot be added on the fly, but predefined linking of functions between WASM modules is indeed possible.

Bellow are links to example WAT files that accompany the book WebAssembly: The Definitive Guide. These examples show linking of WASM module functions via tables. The idea is that one modules contains function definitions while the other one providing linking contains pretty much just function callers.

https://github.com/bsletten/wasm_tdg/blob/main/ch07/math2.wat
https://github.com/bsletten/wasm_tdg/blob/main/ch07/mymath.wat

[arctic-hen7]

I think this would be a great feature in the longer term, but for now Wasm code splitting is still in its infancy, and I'd like to focus on more essential features like hot reloading at the moment.

That said, I think this issue should be kept open for discussing the feasibility of this, and I'm happy to look at it as an experimental feature for v0.4.0!

[arctic-hen7]

Some version of this can be supported for prerendered resources (not the Wasm bundle yet though) through #4, it's just worth noting. That would make the app only fetch the parts of a page that have changed between two loads (as defined in an islands system by the user).

[arctic-hen7]

See #150 for an interpretation of this that involves delaying the loading of some of the state of a page so that the user can see a page more quickly when something quite heavy is being sent through.

As for Wasm code splitting, this is an issue most certainly on my radar now, and something I intend to devote substantial time to in 2023 once #150, #221, and #4 are resolved. This will likely end up in v0.5 or v0.6.