4 ms·

Interesting. So a front end could utilize HTMX to do dynamic client side rendering without javascript, limiting what goes server-side to only the things the ser

Interesting. So a front end could utilize HTMX to do dynamic client side rendering without javascript, limiting what goes server-side to only the things the server needs. Sounds very promising. The code looks a bit complicated though. Some explanation of what’s going on would be helpful.

FpUser 4y ago
There is no "without javascript" here. There is a javascript library linked to your html and it then modifies / supplements behavior of the DOM elements. Javascript / DOM / HTML / CSS is super dynamic and flexible combo that can do what looks like a miracle to unfamiliar.
- mattlondon 4y ago
  It does however raise an interesting question - can we ship the "server" part of a SSR rendered app as a WASM blob? 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
  - 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 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. 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?
dimavs 4y ago
There is a nice Rust-only web framework already - yew. One of the examples https://github.com/security-union/yew-beyond-hello-world https://github.com/security-union/yew-beyond-hello-world
- EugeneOZ 4y ago
  And a few others: https://blog.logrocket.com/current-state-rust-web-frameworks/ https://blog.logrocket.com/current-state-rust-web-frameworks...

FpUser 4y ago

There is no "without javascript" here. There is a javascript library linked to your html and it then modifies / supplements behavior of the DOM elements. Javascript / DOM / HTML / CSS is super dynamic and flexible combo that can do what looks like a miracle to unfamiliar.

mattlondon 4y ago
It does however raise an interesting question - can we ship the "server" part of a SSR rendered app as a WASM blob? 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
- 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 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. 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?

dimavs 4y ago

There is a nice Rust-only web framework already - yew. One of the examples https://github.com/security-union/yew-beyond-hello-world https://github.com/security-union/yew-beyond-hello-world

EugeneOZ 4y ago
And a few others: https://blog.logrocket.com/current-state-rust-web-frameworks/ https://blog.logrocket.com/current-state-rust-web-frameworks...