31–40 of 69 posts
It seems like the two approaches are at odds with each other anyway, so perhaps this won't ever be possible.
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA. Any open source project done in HTMX that ha…
The great part of this, too, is caching these responses is still simple with the a `Vary: HX-Request`
One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely". This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or…
It's not an XOR proposition.
One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely". This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or…
Earlier quoted context omitted.
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/
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…
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)
Earlier quoted context omitted.
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/
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…
One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely". This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or…
HTMX users just use existing JS components. It's not an XOR proposition.
Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents.
It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway.
I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA. Any open source project done in HTMX that ha…
Earlier quoted context omitted.
Why did WPF go out of style? (or did it? idk) It seems like a good pattern, but it's always good to look at historical cases for the gotchas
XAML is not a learn in a weekend type of deal and most dev don’t want to put the time to reading a proper book to learn it.
Does your backend has components? Does your scripting toolkit has components?
HTMX doesn't care either way, and will use whatever you give it.
You can pick reusable django forms, alpine js, some manually created boundaries, a jquery module... You can even drop react on a single page because there is a widget you like and it's not loaded often.
People may be tempted to talk about HTMX using irrelevant points of references.
It's not providing an SPA with a component architecture, that's the point.
The readers that are very used to modern JS stacks and never had to deal with the web before 2010 may want to read:
https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1
This will give a better idea of how to think in HTMX, which is just a new trick for an old dog.
It's better to use this tool for what it is, with its limits and strengths rather than trying to make it into something it's not.
The reason HTMX can't do many things react is good at is because it's by nature the opposite of react.