upvote
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.
reply
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).
reply
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.

reply
"Complex mini app" is one hell of a concept.
reply
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.
reply
A text editor or music player is hardly "mini".

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.

reply
> A text editor or music player is hardly "mini".

If it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”.

For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context.

reply
Having adopted Angular 1 back when it was new, I can promise you it's completely different than Htmx.
reply
What is the main difference?
reply
Astro then.
reply
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.
reply
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).
reply
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.

reply
> 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.

reply
> 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.

https://data-star.dev/examples/dbmon

reply
deleted
reply
right, so use the right tool for the job. most apps are boring CRUD apps and dont support chat.
reply
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.
reply
That "massive hack" is supposed to be one of the core features of React.
reply
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.

reply
For what it's worth, Claude Code is really good with HTMX and with adding that glue logic if needed.
reply
But it is different this time, we are going back to HTML! /s
reply
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!)

reply