4 ms·

I'm not sure I fully understand the composable part. To me this seems like server-side rendered HTML on the one end (which indeed makes it easier to debug), and

by larve 3y ago

I'm not sure I fully understand the composable part. To me this seems like server-side rendered HTML on the one end (which indeed makes it easier to debug), and a react version on the other end. React would instead of passing the object directly to the renderer (as one can do when doing it all in one process), have some fetching mechanism. In terms of composability, react seems more composable to me. I can delegate the distributed and state aspect to something like redux / redux query, and fully concentrate on the composable component system. The added benefit is of course to separate backend and frontend concerns, which might or might not be to your like or useful within a certain project's scope.

mejutoco 3y ago
I think the key feature of htmx that often people overlook is that you can update several elements with one html response The attribute is the following: https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/
- 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.
- zaphod420 3y ago
  Oh, I was wondering how to do this with HTMX! I wish the documentation was more verbose, and had some examples. It's a little hard to understand how to use with how minimal the docs are. edit: just found the example. https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-content/
whizzter 3y ago
I think many "clean" abstractions are about making a certain layer (horizontals) in a tech stack is clean, whereas functional parts in actual applications are most cleanly separated as functional verticals. But if you follow a clean vertical separation you will run into issues when horizontals (like common styling in a web-app or coherent network failures handling in many applications ) isn't handled cleanly. For really clean applications you want your design to be a DAG, focusing on horizontals or verticals often leaves people with messes when you violate DAG constraints in the other direction. What the author has issues with is that React frontend-monoliths would need extra machinery to work with separate compilation steps to allow separate building of verticals, with something like HTMX it's fairly loose (And separately worked on verticals can easily co-exist). I think that this is part of the big divide between people who came from classic web-dev backgrounds and more latecomers from other domains (often manifested by the love or hate of DHH and his anti-TS/React stance). Web-dev people would naturally land on writing verticals (one page = one task) and whilst their common abstractions could be horrible (SQL everywhere) they accomplished tasks well but cleaning up architectural messes could be bad. Classic developers outside of web often saw applications, servers,etc (horizontals) as their main unit and made those clean, keeping the horizontal clean (like network failure handling) would influence design decisions (often at the expense of vertical concerns). React allows for composability internally but often re-introduces issues on a larger scale, like your Redux store needs to know about parts from perhaps both user-admin and more application specific tasks. Now this is fine if it's a separately distributed application (like a mobile app) but people used to just handle one vertical at a time might feel that it's a lot of extra work other more contained cases.

by larve 3y ago

mejutoco 3y ago

I think the key feature of htmx that often people overlook is that you can update several elements with one html response The attribute is the following: https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/

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.
zaphod420 3y ago
Oh, I was wondering how to do this with HTMX! I wish the documentation was more verbose, and had some examples. It's a little hard to understand how to use with how minimal the docs are. edit: just found the example. https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-content/

whizzter 3y ago

I think many "clean" abstractions are about making a certain layer (horizontals) in a tech stack is clean, whereas functional parts in actual applications are most cleanly separated as functional verticals. But if you follow a clean vertical separation you will run into issues when horizontals (like common styling in a web-app or coherent network failures handling in many applications ) isn't handled cleanly. For really clean applications you want your design to be a DAG, focusing on horizontals or verticals often leaves people with messes when you violate DAG constraints in the other direction. What the author has issues with is that React frontend-monoliths would need extra machinery to work with separate compilation steps to allow separate building of verticals, with something like HTMX it's fairly loose (And separately worked on verticals can easily co-exist). I think that this is part of the big divide between people who came from classic web-dev backgrounds and more latecomers from other domains (often manifested by the love or hate of DHH and his anti-TS/React stance). Web-dev people would naturally land on writing verticals (one page = one task) and whilst their common abstractions could be horrible (SQL everywhere) they accomplished tasks well but cleaning up architectural messes could be bad. Classic developers outside of web often saw applications, servers,etc (horizontals) as their main unit and made those clean, keeping the horizontal clean (like network failure handling) would influence design decisions (often at the expense of vertical concerns). React allows for composability internally but often re-introduces issues on a larger scale, like your Redux store needs to know about parts from perhaps both user-admin and more application specific tasks. Now this is fine if it's a separately distributed application (like a mobile app) but people used to just handle one vertical at a time might feel that it's a lot of extra work other more contained cases.