Maybe I’m missing something, but why would you want HTMX server side rendering, rather than a restful API that can return platform-agnostic data structures that you could render in various contexts, like a SPA, or a mobile app, or a terminal app, etc?
- If the server is responding with JSON, the client has to parse, decode, and validate the JSON. Then it has to transform it into HTML DOM nodes. Finally, it can inject them into the DOM.
- If the server is responding with a bespoke non-JSON data structure, it's the same situation as above except even more work because a third-party, non-standard library has to decode this structure into something (most likely JSON) and then transform the JSON into HTML nodes, etc. etc.
- If the server is responding with straight-up HTML, the client uses the browser's HTML parser to directly transform it into HTML nodes and inject it into the page. And by the way, the browser engine is essentially a function that is highly optimized for exactly this use case–parsing bytes into DOM nodes.
'We' might use the same API but it's widely accepted that generally the same API doesn't work for all contexts. See https://samnewman.io/patterns/architectural/bff/#general which details the many well-known problems with having a single API for different contexts.
Yes but isn’t this the beauty of decentralized protocols? The cost is spread amongst all, it doesn’t require one entity to shoulder the cost for everyone.
It’s not really decentralized in that way. If you’re loading a bunch of pages in your mobile browser, your device is paying the power consumption cost of deserializing, parsing, and running all that JS. It doesn’t save on that because some other user also did it.
