4 ms·
> "can we ship the "server" part of a SSR rendered app as a WASM blob?" What problem would that solve, and how is that any different than how websites already
by csmpltn 4y ago
> "can we ship the "server" part of a SSR rendered app as a WASM blob?"
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.
- mattlondon 4y agoI mean eliminate client side JavaScript. Move all logic to wasm (making API calls to the backend server for raw data as needed) and have the WASM emit plain HTML and the absolute minimum of js to wire up the service worker and intercepts. No virtual dom, no components, no jsx etc - just plain HTML from the WASM blob. 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.
- resoluteteeth 4y ago> I mean eliminate client side JavaScript. Move all logic to wasm (making API calls to the backend server for raw data as needed) and have the WASM emit plain HTML and the absolute minimum of js to wire up the service worker and intercepts. No virtual dom, no components, no jsx etc - just plain HTML from the WASM blob. How is this different from or better than current WASM-based frameworks?