[meowtimemania]

I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.

[emseetech]

UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind.

Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.

We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.

[taberiand]

I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript

[aurareturn]

So why complicate things and just use something like React + Next.js, which is already designed for complex apps?

[emseetech]

Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.

[kaoD]

Web components are the stuff that nightmares are made of.

The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way.

The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic.

Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.

Overall not a great experience for user-facing apps.

[throwitaway1123]

> Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.

You can SSR web components using the Declarative Shadow DOM API, which is finally supported in all of the major browsers and works without JS.

[emseetech]

| Web components are the stuff that nightmares are made of.

There's lit.dev for an easier approach.

https://lit.dev

[kaoD]

But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities.

At that point why not just use React? What do I get from using Lit instead?

[librasteve]

I have been musing in going in this direction - but your post has lowered this idea in my project plan for now ... thanks!

[taberiand]

I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc.

I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them)

The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.

[synergy20]

i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.