We spent 12 years on https://qbix.com/platform https://qbix.com/platform and along the way saw a lot of fads come and go. At one point we experimented with the

We spent 12 years on https://qbix.com/platform https://qbix.com/platform and along the way saw a lot of fads come and go. At one point we experimented with the server returning the stuff to replace the HTML with. We support that in our framework natively (through a mechanism called “slots”). That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first. Imagine your site being composed of static files (eg served on Hypercore or IPFS via beaker browser). As more people use it, the swarm grows. No worries about being DDOSed. No having to trust a server to not send you the wrong interface one day. The software is yours. It just got delivered via a hypercore swarm or whatever, and your client checked the Merkle trees to prove it hasn’t been tampered with. The you just interact eith a lot of headless web services. Rather than bearer tokens and cookies, you can use webauthn and web crypto to sign requests with private keys. You can do a lot more. And you store your data WHERE YOU WANT. Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client. Returning markup language like HTML actually mixes data with presentation. Consider what happens when you want to return a lot of rows. With JSON, you return just the structured content. With HTML, there is a lot of boilerplate <li class=“foo” onclick=“…”> mixed in there which is a lot of extra weight on the wire. If you are interested in learning more, I gave a whole talk about it: https://qbix.com/blog/2020/01/02/the-case-for-building-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...