3 ms·

that's even easier to do in react though. If I say, update the cart, and update my cart state in redux, then every component rendering the cart (say, header, ch

by larve 3y ago

that's even easier to do in react though. If I say, update the cart, and update my cart state in redux, then every component rendering the cart (say, header, checkout component, shipping progress bar) will update seamlessly. To me htmx seems weird in its mixing of logic / API separation layer with the UI separation layer. I can see it making sense on single/small team projects and appreciate the lack of bundling and async communication and all the issues JS entails, but composability is not the argument that makes sense to me.

mejutoco 3y ago
It definitely feels weird in htmx. It is easier in React if you are using a centralised state manager, yes. I prefer it, it is more explicit. If you use Context to set state it can come from anywhere. In this sense, it is even easier in Elm, since if you use Elm you are using one (redux was inspired by it iirc) ;o) I think htmx makes sense really at the html level, like rest (I believe that is the goal of the project), because it would be framework agnostic. Then some boilerplate on top would fix these issues. You could define some central state in a single place and generate all the references (hx swap oob attributes). The basis is solid imho. The most attractive thing for me would be that it would stay stable (like rest), but I agree right now a subset of react (choose state manager, styling method, ssr, etc) is easier/quicker. It needs to be constantly updated, though, and dependencies can creep in quickly if a team is not disciplined enough. I agree with the weirdness of mixing logic an ui. I remember when css, html, and js were supposed to be kept separate. Then components in jsx mixed them, and it was useful. If htmx proves useful, the mixing of concerns does not differ much (not the same but it rhymes)
seiferteric 3y ago
I am not a web dev, but I do it occasionally for fun, or want to put a script on the web, and when I saw htmx I was excited because I immediately grokked it and knew how to use it for my purposes. React looks cool, but intimidating for someone who is not a web dev. Maybe htmx is not for making big complex apps.
_heimdall 3y ago
That's where looking at HTML as serialized state really helps. When a request changes the cart the server responds with chunks of HTML "state" for anything that changed. In the shopping cart case, a user clicks Add to Cart and the server responds with an update for the button (maybe it has a success message) + new HTML for the cart item counter in your header. Sure that counter is technically UI, but the server is sending it because the state has changed and the client needs to patch in the update.

by larve 3y ago

mejutoco 3y ago

It definitely feels weird in htmx. It is easier in React if you are using a centralised state manager, yes. I prefer it, it is more explicit. If you use Context to set state it can come from anywhere. In this sense, it is even easier in Elm, since if you use Elm you are using one (redux was inspired by it iirc) ;o) I think htmx makes sense really at the html level, like rest (I believe that is the goal of the project), because it would be framework agnostic. Then some boilerplate on top would fix these issues. You could define some central state in a single place and generate all the references (hx swap oob attributes). The basis is solid imho. The most attractive thing for me would be that it would stay stable (like rest), but I agree right now a subset of react (choose state manager, styling method, ssr, etc) is easier/quicker. It needs to be constantly updated, though, and dependencies can creep in quickly if a team is not disciplined enough. I agree with the weirdness of mixing logic an ui. I remember when css, html, and js were supposed to be kept separate. Then components in jsx mixed them, and it was useful. If htmx proves useful, the mixing of concerns does not differ much (not the same but it rhymes)

seiferteric 3y ago

I am not a web dev, but I do it occasionally for fun, or want to put a script on the web, and when I saw htmx I was excited because I immediately grokked it and knew how to use it for my purposes. React looks cool, but intimidating for someone who is not a web dev. Maybe htmx is not for making big complex apps.

_heimdall 3y ago

That's where looking at HTML as serialized state really helps. When a request changes the cart the server responds with chunks of HTML "state" for anything that changed. In the shopping cart case, a user clicks Add to Cart and the server responds with an update for the button (maybe it has a success message) + new HTML for the cart item counter in your header. Sure that counter is technically UI, but the server is sending it because the state has changed and the client needs to patch in the update.