[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?

[emseetech]

I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step.

The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have.

| no SSR nor progressive enhancement

I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?

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