[arch1e]

As someone who tried to build a fairly large project with HTMX + Go, I can say it just wasn't there for me. Maybe it will get there eventually, but I'm not convinced.

For simple CRUD apps and admin dashboards, HTMX is great. But once you have lots of interconnected components, shared state, and complex interactions, managing everything quickly becomes difficult.

I originally chose HTMX because I really didn't enjoy working with React. Eventually I tried SvelteKit, and it completely changed my perspective. I still use Go for the backend, but SvelteKit in SPA mode for the frontend. It gives me a clean separation between the two while making complex UIs much easier to build and maintain.

What really sold me was that Svelte feels like a natural extension of HTML rather than a different language with JSX. State management is simple, the component model is intuitive, and the new `$state` syntax is especially nice.

[nymanjon]

With HTMX 4.0 it might be a bit nicer. I use my own home-grown HTMZ-BE lib/snippet that has the back end decide where to place the elements. Deciding from the back end makes it so you go from a lot of eventing on the front end to middleware on the back end, which significantly reduces the complexity of the application. And then when you do have a lot of interactivity you just send down the whole interactive area and have morphdom (HTMX uses idiomorph, I believe) which will do a comparison of the DOM compared to what your new HTML is and update just what needs to be updated.

I've found that to really reduce the complexity of my applications. If I really do need something more powerful with state machine interaction, then I use VanJS. But, really, I've only used that for my static sites where I need a little interaction on the front end and no back end connection.

Here's an example of using HTMZ-BE (which can easily be extended to HTMX 4.0 and Data-Star - if you need even more features).

https://github.com/jon49/Soccer

It also uses an _<action> attribute pattern on the HTML for simple, declarative front end state interaction. Makes the user's life a little nicer.

It's amazing how simple things can be if you work with it and think about, "I want simplicity." A lot of the front end frameworks add a lot of complexity, even nice frameworks like Svelte, I think because the paradigm is just wrong.

[designerarvid]

Isn’t the whole point of HTMX philosophy to question whether you need interconnected components with shared state? Most apps are doing crud on a database at the end of the day.

[pepperoni_pizza]

I think it very much depends on what you're doing. Would it make sense to build Google Docs in HTMX? Probably not. Does it make sense to roll out SPA + JSON API for something that is basically a reskinned Django Admin? Probably not.

[intrasight]

Yes. And additionally most "apps" are just static web sites with static components.

[solatic]

Just curious: the people behind HTMX have a frontend sibling project called Hyperscript, which handles stuff like frontend state: https://hyperscript.org/docs/reactivity/

Did you give it a try?

[asdfsa32]

At that point just use React.

[solatic]

I'm not convinced. Hyperscript's reactivity model is highly greppable, and it keeps the no-build approach to Web frontend interactivity. It's "just enough" in the same way that HTMX is.

React probably scales better for huge engineering divisions, but that isn't who the GOTH stack is aiming for anyway.

[mixmastamyk]

The htmx site is clear about tradeoffs and that it is not suitable for that use case. Though you have to dig for the articles.