wasm-bindgen and it's ecosystem is massively useful but also very complex.
It is possible to interact with web APIs with a thin wrapper API instead of wasm-bindgen
Pros:
Cut web build times dramatically (Web would become the fastest platform to build)
May unblock WebWorker and AudioWorklet capabilities that wasm-bindgen cannot currently handle.
More kapp logic can exist on the Javascript side, instead of trying to awkwardly put it into Rust.
Much simpler stack
Potentially better performance by reducing back and forth between Wasm and JS (but may be insignificant)
More control over destiny: wasm-bindgen leadership has been focused on other things over the last year, development might slow down.
Cons:
Web APIs are not automatically wrapped. There are a ton of them and kapp would have to add them as needed. Adds more friction to new features.
Losing expertise of wasm-bindgen.
Harder to integrate with other Rust crates that use the Rust ecosystem standard of wasm-bindgen
wasm-bindgen-cli performs some optimizations that would be lost.
Potentially more difficult to integrate with Javascript libraries.
Obviously it takes time to port libraries to the new thin wrapper. In particular glow depends on wasm-bindgen so new GL bindings would be needed, which would not be hard but would take some time.
Some of this work is already started on the kwasm branch: https://github.com/kettle11/kapp/tree/KWasm
I intend to investigate / continue work on the branch in the near future.
wasm-bindgen
and it's ecosystem is massively useful but also very complex.It is possible to interact with web APIs with a thin wrapper API instead of
wasm-bindgen
Pros:
WebWorker
andAudioWorklet
capabilities thatwasm-bindgen
cannot currently handle.kapp
logic can exist on the Javascript side, instead of trying to awkwardly put it into Rust.wasm-bindgen
leadership has been focused on other things over the last year, development might slow down.Cons:
kapp
would have to add them as needed. Adds more friction to new features.wasm-bindgen
.wasm-bindgen
wasm-bindgen-cli
performs some optimizations that would be lost.glow
depends onwasm-bindgen
so new GL bindings would be needed, which would not be hard but would take some time.Some of this work is already started on the
kwasm
branch: https://github.com/kettle11/kapp/tree/KWasm I intend to investigate / continue work on the branch in the near future.