5 ms·

> when you dont have to update the app in any other places when your state change You can replace elements outside of your direct tree if you want. The simples

> when you dont have to update the app in any other places when your state change You can replace elements outside of your direct tree if you want. The simplest case you replace the whole page and pick what elements you actually want to change. You're thinking about HTMX wrong. It's for progressive enhancement, the default is a full page reload and then you progressively enhance parts of the HTML. You should be using the same code paths and template to generate the islands of interactivity as you do for the whole page. You can then optionally send less HTML by just sending the parts that you expect to have actually changed, your "islands".

LudwigNagasena 2y ago
> You can then optionally send less HTML by just sending the parts that you expect to have actually changed, your "islands". And then you end up with modern SSR frameworks that do the bookkeeping for you.
- Imustaskforhelp 2y ago
  yes but mostly the island architecture is only dominant in the javascript world we can basically get the benefits of spa without having to learn js / use minimal js using htmx in some sense https://github.com/donseba/go-htmx https://github.com/donseba/go-htmx check this out
- dingnuts 2y ago
  If you render HTML on the client you still have to render a transport format (usually JSON) on the server side. Sending HTML just lets you skip the transport format and the client side rendering.
  - LudwigNagasena 2y ago
    And letting your framework do the bookkeeping for you lets you skip the whole issue. I don't know the exact specification of React Server Component Payload, but I know that it somehow changes stuff on the client-side when the client interacts with the server. (It sends something like `["$","p",null,{"children":["a child","another child"]}]`)
- traverseda 2y ago
  It's still one server side template, you just render different parts depending on what is calling it. By default render a full page, if you want to get precious about a few dozen KB from sending a full page over the wire you can toggle some blocks off.
swyx 2y ago
appreciate that. ive been given the progressive enhancement spiel a few times. its obviously a judgement call that will be the right call for some people. but i think many people underestimate how requirements grow over time because our UI standards have gone up over time, even for basic sites that you dont traditionally think of as SPAs. data drives everything, you want your UI to be a function of data. for the other stuff, the growing browser stdlib has basically replaced most of jquery's usecases. so (in the most non condescending or negative way possible) htmx occupies a very awkward sliver between "The Platform" and Frameworkland and after giving it some time I have yet to see the benefit from keeping any of it in my head
- poincaredisk 2y ago
  I'm obviously in the minority, but I breathe a sigh of relief every time I encounter a website that works workout JS, don't hijack basic browser functionality, don't make dozens of AJAX requests in the background, and overall just focuses on presenting the data I want.
  - mpweiher 2y ago
    I don't think you are in the minority. At all. Every time web sites reimplement basic browser behavior, which they invariably do these days, they get worse, often significantly, because they never get it right.
- yawaramin 2y ago
  > i think many people underestimate how requirements grow over time because our UI standards have gone up over time I think you are overestimating how much 'UI standards' have gone up over time, actually. Nobody except for a small 'extremely online' set of people and control-freak designers care about all those complex UI/UX requirements. Users certainly don't care. They want fast-loading, responsive pages that get out of the way and don't drain their batteries or clog up their connection. The other thing here is that approximately no one can actually tackle the complexity introduced by SPA frameworks and 'UI standards', and it's far more likely that they bungle it up and make giant, wasteful, UX pitfall-ridden apps. With server rendered pages, plain old HTML, and progressive enhancement, we at least have a better chance of producing something usable.

LudwigNagasena 2y ago

> You can then optionally send less HTML by just sending the parts that you expect to have actually changed, your "islands". And then you end up with modern SSR frameworks that do the bookkeeping for you.

Imustaskforhelp 2y ago
yes but mostly the island architecture is only dominant in the javascript world we can basically get the benefits of spa without having to learn js / use minimal js using htmx in some sense https://github.com/donseba/go-htmx https://github.com/donseba/go-htmx check this out
dingnuts 2y ago
If you render HTML on the client you still have to render a transport format (usually JSON) on the server side. Sending HTML just lets you skip the transport format and the client side rendering.
- LudwigNagasena 2y ago
  And letting your framework do the bookkeeping for you lets you skip the whole issue. I don't know the exact specification of React Server Component Payload, but I know that it somehow changes stuff on the client-side when the client interacts with the server. (It sends something like `["$","p",null,{"children":["a child","another child"]}]`)
traverseda 2y ago
It's still one server side template, you just render different parts depending on what is calling it. By default render a full page, if you want to get precious about a few dozen KB from sending a full page over the wire you can toggle some blocks off.

swyx 2y ago

appreciate that. ive been given the progressive enhancement spiel a few times. its obviously a judgement call that will be the right call for some people. but i think many people underestimate how requirements grow over time because our UI standards have gone up over time, even for basic sites that you dont traditionally think of as SPAs. data drives everything, you want your UI to be a function of data. for the other stuff, the growing browser stdlib has basically replaced most of jquery's usecases. so (in the most non condescending or negative way possible) htmx occupies a very awkward sliver between "The Platform" and Frameworkland and after giving it some time I have yet to see the benefit from keeping any of it in my head

poincaredisk 2y ago
I'm obviously in the minority, but I breathe a sigh of relief every time I encounter a website that works workout JS, don't hijack basic browser functionality, don't make dozens of AJAX requests in the background, and overall just focuses on presenting the data I want.
- mpweiher 2y ago
  I don't think you are in the minority. At all. Every time web sites reimplement basic browser behavior, which they invariably do these days, they get worse, often significantly, because they never get it right.
yawaramin 2y ago
> i think many people underestimate how requirements grow over time because our UI standards have gone up over time I think you are overestimating how much 'UI standards' have gone up over time, actually. Nobody except for a small 'extremely online' set of people and control-freak designers care about all those complex UI/UX requirements. Users certainly don't care. They want fast-loading, responsive pages that get out of the way and don't drain their batteries or clog up their connection. The other thing here is that approximately no one can actually tackle the complexity introduced by SPA frameworks and 'UI standards', and it's far more likely that they bungle it up and make giant, wasteful, UX pitfall-ridden apps. With server rendered pages, plain old HTML, and progressive enhancement, we at least have a better chance of producing something usable.