I've found Htmx to be smug and misleading. "Look how simple it is! No JavaScript! Ignore the fact that you need a complex backend in a separate language and environment to generate your html."
Some of the people you're dismissing have probably been using JavaScript for a lot longer than you have.
<button hx-get="/confirmed"
hx-trigger='confirmed'
onClick="Swal.fire({title: 'Confirm', text:'Do you want to continue?'}).then((result)=>{
if(result.isConfirmed){
htmx.trigger(this, 'confirmed');
}
})">
Click Me
</button>
<div hx-get="/clicked" hx-trigger="click[ctrlKey]">
Control Click Me
</div>
<form id="example-form" hx-post="/test">
<input name="example"
onkeyup="this.setCustomValidity('') // reset the validation on keyup"
hx-on:htmx:validation:validate="if(this.value != 'foo') {
this.setCustomValidity('Please enter the value foo') // set the validation error
htmx.find('#example-form').reportValidity() // report the issue
}">
</form>
<button @click="doThing">
In Vue. Or just plain old JS onclick in Svelte.
By comparison, HTMX is illegible
<button hx-get="/confirmed" hx-trigger="Do you want to continue?">Click Me</button>
The second example: really? The words 'get' and 'trigger' don't tell you what it's going to do?
> Htmx's own examples push you to code that is unorganized and inaccessible.
You realize these are demo, ie sample code right? No one is forcing you to write exactly that code? You can write organized and accessible code in your own project?
And the second example is not accessible. It should be a button.
A library’s demo/sample code should present best practices, not worst.
> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.
It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.
And even if it was - I would be prepared to suffer a lot of pain to avoid the javascript build pipeline and framework churn.
SPA frameworks drove me away from front-end dev and HTMX is making me consider returning.
And I fully accept that "web apps" probably need complex frameworks. I just think most people aren't really building web apps - they are building web sites.
In the remaining example, IMO it looks about as organized and accessible as I can imagine as far as HTML goes - my one complaint being the use of a div instead of something more semantically meaningful.
It’s just people would rather write a low level, well-designed language than maintain JS codebases.
Backend in a language that isn't JavaScript is a feature.
Also, a backend where you just serve a template instead of full layout (server-side rendered app) or JSON (client-side rendered app) is not more complex in most of scenarios.
None of that goes away, of course, it just moves to a different repo.
Actually, duplication of state, routing logic, auth logic, etc. really do get eliminated. Because we're maintaining all that on the server-side only and not having to reproduce it on the client side. It's a huge win.
But your larger point stands, HTMX is probably not a great fit for highly interactive webapps, even though you can push it pretty far
So before clicking 'next':
<a disabled>prev</a>
<span>Page 1</span>
<a href="/page/2" hx-get="/page/2">next</a>
<a href="/page/1" hx-get="/page/1">prev</a>
<span>Page 2</span>
<a href="/page/3" hx-get="/page/3">next</a>What happens when you click quickly? Does the UI just freeze until it eventually loads... some slide? What if you want a touch carousel using scroll-snap? How do you destroy and replace the entire section without interrupting the user?
> No more state!...Just use htmx, everything becomes so simple!...None of that goes away, of course, it just moves to a different repo.
With a purely client-side component, the state is managed purely on the client side, and the server would not touch it anyway. So it didn't have duplication of state to begin with, and htmx is solving (among other things) the duplication of state problem. So again–this example is not relevant to htmx.