There are many applications where htmlx is objectively the best tool. But i really hate all the hype around it and people pushing it as react replacement.
Had an heated debate with someone that was really angry at everything react, for good reasons, but being oblivious that htmx can't replace client side logic. React hype + backend crowd I guess.
as a primarily backend dev I really don't see the appeal here. So now I need to make endpoints for every little UI element that I want to be updated by user interactions? And somehow keep it styled and matching all of the UI elements rendered on the frontend? No thanks, I'll just give you data and you can present it however you please.
> So now I need to make endpoints for every little UI element that I want to be updated by user interactions?
No. Htmx supports extracting a subset of received HTML and merging it with the current page.
So, for a typical form, you _could_ do a request to validate the entire form then extract the relevant error message for the input field that triggered said request.
This would re-use most code of the actual form submit endpoint except it _only_ does the validation.
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
When using Htmx, the backend would typically own the frontend. So the styles and UI elements are already "matched" as it were.
> No thanks, I'll just give you data and you can present it however you please.
This makes sense when there are multiple frontends and/or consumers of the API. When there is exactly one API consumer, and that API consumer is the frontend, Htmx can save a lot of time by reducing the overall complexity of the project.
> So now I need to make endpoints for every little UI element that I want to be updated by user interactions?
What's the alternative?
You want interactivity that users can trigger. You'd need to call an endpoint in some way or another, giving you updated data, no?
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
Wait, how are your other UI elements rendered? How are they styled?
Somewhere in your code, you'll have a step where you generate HTML with CSS classes. It's popular to use React for this step, or some form of SSR where you render HTML templates.
With HTMX, you can simply reuse the same backend SSR templates that you were already using, and extract some parts of it which you want to be interactive.
These will be rendered whenever you trigger an action, by HTMX fetching that part of the template.
If you want to strictly split frontend and backend development for some reason, you can totally do it: You'd have a business logic layer that provides data to the view layer within your app (be it JSON, or POJOs), and the frontend team styles that data in the view layer however they please.
And the benefit is that you'd all render it on the server. No need for the client's browser to do anything anymore. It's all coming pre-rendered, cacheable and indexable. Done.
Most applications that would leverage this (e.g. server-side rendered Rails or Laravel or Django) already have those templates as partials for their views, so leveraging the functionality is trivial.
I think there is definitely a place for “unobtrusive JS” “HTML over the wire” framework. But it should have a clear path for upgrading to conventional SPA stack where needed. Maybe the upcoming Next.JS replacement will have SPA part as optional and will be “unobtrusive JS” “HTML over the wire” by default.
