[giraffe_lady]

I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.

[gochi]

The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.

[spinningslate]

That's not my experience based on two scenarios:

1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;

2. Dotnet back end with Angular front end.

In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.

The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.

Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.

[gochi]

Not sure you've solved the complexity when you've just slotted in another front to a general solution that is over-engineered. You could have replaced either scenarios with a single NextJS or SvelteKit solution. Go above and beyond in "complexity", write your Node backend (keeping it one language, JavaScript), and use vanilla HTML and JS to consume that.

To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).

[adamckay]

> My history was mostly JQuery where needed (which was all the time before JS got its act together).

htmx should remind you of those times.

I certainly has for me - it's just (fundamentally) a fancy and clever wrapper around jQuery ajax requests made via HTML attributes.

[sznio]

> You could have replaced either scenarios with a single NextJS or SvelteKit solution.

But then I would be using only JS. I want a backend to be something else so that I don't go insane.

[unshavedyak]

The difference is those were already tools we were using. You _(hypothetically?)_ can't eliminate the complexity of dynamic apps without limiting flexibility. However you can move the complexity in-band, to a domain you are already using and preferring.

Plus, if it's done right, you can get a lot of functionality while remaining No-JS friendly.

[rakoo]

With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.

[CharlesW]

> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language.

Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.

[wrapperup]

Much of your business logic can live in the backend, and it keeps your frontend really tiny. The idea is to generate HTML on the backend, instead of using a front-end framework to generate HTML on the client from an API call.

You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.

[CharlesW]

> Much of your business logic can live in the backend, and it keeps your frontend really tiny.

Ah, so "with htmx you can use any language" is true because its users are no longer using a programming language per se for the front-end, but instead are defining logic with htmx's DSL?

[rakoo]

htmx extends html to generalize a behaviour that already exists, so it's as much a DSL as html itself is a DSL

[rakoo]

Yes, but you still need to write the frontend code in JS/TS

[wrapperup]

Yep, indeed. But htmx can reduce that a lot (to 0 even, in some instances), which is why it's really nice.

There's also WASM, which is slowly gaining steam, but it still isn't a first class citizen like JS is.

[andy800]

I see it as much more, many things can be stripped out altogether. Client-side state management. Client-side input validation. Fallbacks for when data hasn't been loaded yet. Less async-based code, less coordination-required and event-driven code (this stuff happens but much easier and often code-free with HTMX).

Its not a fit for every site or use case but more than any other front-end tool or library or framework, it has enabled me to actually realize the UI concepts in my head to the actual screen, and usually a lot quicker than I'd expect.

[zarzavat]

So you only do input validation on submit? Isn’t that user hostile?

This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.

[andy800]

Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/

Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).

In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.

[zarzavat]

Disagree that it’s good UX. Now the user only gets feedback when they lose focus on the field, forcing them to go back and refocus it. In conventional React they get feedback on each keystroke allowing errors to be fixed while the field is still focused.

[andy800]

So when the person is starting to enter an email address, the page goes red until he enters the .com at the end? He gets an error for the first 9 digits of a phone number? Do you implement debouncing?

There isn't one thing called "conventional React", there are all kinds of validation libraries on npm and many strategies laid out on Stack Overflow. https://stackoverflow.com/questions/41296668/how-do-i-add-va...

I think it's fair to say we have different opinions on good UX, no need to debate it any further

[Xeamek]

I mean, that literally the core concept entire field of programming: making abstractions to shift complexity around (else where)

[giraffe_lady]

For many basic & routine web page interactions, I have not found that to be true.

[gochi]

I can only see that experience being true if you've never used jquery (aka the same shorthands you're relying on within htmx and likely hyperscript).

[giraffe_lady]

My frontend experience predates the rise of react etc. I have used jquery.

The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag.

Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.

[thom]

Most of my experience using jQuery was on sites that required progressive enhancement, and the easiest way to do that was to create an htmx-style framework anyway.

[Spivak]

I think the biggest change from jQuery flows is that the behavior is attached to the elements themselves instead of a script over here poking at the dom from the outside.