The code looks a bit complicated though. Some explanation of what’s going on would be helpful.
So you have a client side app that is 100% static HTML + WASM service worker in the browser, making calls off to some external API as it needs data but otherwise generating static HTML in the browser blob.
I wonder how much slower or faster this would be than a JavaScript heavy UI with traditional server side rendering. You would at least remove the RTT latency
What problem would that solve, and how is that any different than how websites already work today?
There's going to be server-side business logic that can't be "moved" to execute over on the client-side, for security/architectural reasons. On the client, websites already today use JS/WASM.
I have no idea if this would be faster or not than the typical SPA type approach we have with react et al. For simple pages probably not much difference, but for large complex pages ...who knows.
E.g. imagine if you used emscripten to compile PHP or RoR or something into a WASM blob and have a service worker intercept the calls and have the wasm blob "serve" the static HTML without ever leaving the browser (apart from API calls to the server for e.g. database access). Replace PHP/RoR with your server-side thing of choice (homebrew or otherwise)
Bit of a thought experiment I suppose. Not a serious thing but kinda interesting.
How is this different from or better than current WASM-based frameworks?
One of the examples https://github.com/security-union/yew-beyond-hello-world