Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
At that point, gzipped Preact is only 1k larger (and 10k smaller than htmx) and provides a pretty comprehensive and common set of solutions to the majority of front end problems compared to hand rolling everything.
In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality.
In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best.
I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
SSE is perfect for chat/notifications and is a lot simpler than syncing. The server pushes updates to the client doesn't require a sync. SSE is also more performant since it can keep the connection open. The example below is on a $10 vps last I heard.
I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
This is probably true, but I'm pretty happy just using the template engine on the server side and keeping thing DRY as much as possible. Htmx is still going to be faster by orders of magnitude to write and maintain, so choose where to spend your innovation tokens.
What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.
It works quite well, and saves me an awful lot of tedious mucking about with other stuff.
I've been saying for years: All buildings should be parking garages.
Because you can always just put a mini residential building inside a parking garage if you need tenants.
Need an office? Just put a mini office in the parking garage. It's perfect.
Parking garage construction is so clean and simple. Other buildings are too complex! From now on, I'll only build parking garages.
(Then I guess you have the opposite example of the residence without the parking garage! It's a great place to live, but there's nowhere to store my things and park my car!)