These all look reasonable to me.
I especially go back and forth on attribute inheritance (it can be disabled via the htmx.config.disableInheritance option)
Three of the criticisms boil down to the fact that client-side state doesn't always play well w/htmx swaps (especially the simple ones) which is absolutely true.
And events can get crazy. They are powerful, but crazy and at times hard to debug. Such is event-driven life.
The one thing I don't agree with is the default queuing mode: it is not to cancel an existing request and replace it. Instead it is to keep the current request in flight and queue one and only one additional request. I'd need to sit down w/them to see if they were misinterpreting something, using the hx-sync attribute to implement the behavior they mention, or if there is a bug.
I would also like to take this opportunity to market our mug for people who don't like htmx:
I just want to say thank you. Not only because of HTMX, but for being a model and showing what proper "Engineering" should be. Knowing trade - offs and accepting the fact no solution is perfect.
Although that may be because you have a background of Industrial Engineering.
Man, you’re everywhere. I have a Montana’s restaurant in my city and I’m scared to go in because of you.
you should be
By queue only one additional request, do you mean cancel any existing queued request?
the code is a little gnarly, but if you don't specify anything the default behavior is to keep the "last" event that comes in while a request is in flight:
https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56...
and that dumps the existing request queue and puts request created by the last event in it by itself:
https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56...
we don't cancel the current request or issue the next request until the current request finishes
but there could be a bug in the code, for sure, it's pretty crazy
I thought they were complaining that any request is being cancelled by a subsequent one, since they wanted all the requests they made to go through (presumably the requests are altering state?) Probably I misunderstood what was meant by “losing work” though.
yeah i don't know if I understand what they were saying either
regardless if you have a lot of events flying around then updating the UI via hypermedia exchanges is going to be a bad idea, as I mention here:
https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-s...
>https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56...
This seems to be a scenario where switch/case blocks could make the elif-trees a bit easier to read.
Also, the code could use some care about not going so deep into the Vs:
// request headers
if (requestAttrValues.noHeaders) {
// ignore all headers
} else {
for (const header in headers) {
if (headers.hasOwnProperty(header)) {
const headerValue = headers[header]
safelySetHeaderValue(xhr, header, headerValue)
}
}
}
// request headers
if (!requestAttrValues.noHeaders) {
Object.keys(headers)
.filter(hdr => headers.hasOwnProperty(hdr))
.forEach(hdr => safelySetHeaderValue(xhr, hdr, headers[hdr]));
}
yeah i prefer just plain ol' if statements, i find them easier to debug
I’ll definitely pile on with the inheritance causing issues. It made me feel like unsetting them constantly defensively.
You can disable it globally, see htmx.config.disableInheritance:
Not on this in particular but in general: I’ve held off on diving into front end because it’s just such a circus. So many options, so many opinions, so much criticism and then as if that wasn’t enough the whole fkin meta changes monthly. We’re doing react. No actual wasm. Wait no static page. Or maybe htmx. Or vanilla js. Or maybe a mix…well call it remix…it just never ends
I do believe everyone involved means well and aims for technically strong outputs but my good the end result is still fuckin chaos.
Backend and systems programming has people with strongly held opinions and flame wars too but somehow it feels more like a war between gentlemen and less The Purge chaos.
I just don’t understand this opinion.
Backend (and frontend!) can be use stable technology choices if you want to. There are also plenty of bleeding edge libraries/frameworks/languages that come out every week.
As an example, how do you want to deploy your backend? VPS, severless, Kubernetes? What database? Which language? Which libraries?
There are boring stable answers to the above for backend, just like there are boring stable answers to frontend.
Really, I think you’ve just found those boring stable options for the backend and you haven’t done that for the frontend yet.
React has been out for more than a decade and it’s the dominant way of building UIs. And there are pros and cons to this with 1000 solutions, but, really, plain React will work for most things you want to do.
What exactly is "plain React" though? Not sure I've ever seen a project that used only React and nothing else. It would seem you'd need a build step, at the minimum.
Yes, you would need a build step. create-react-app has existed for a very long time and works quite well though advanced applications tend to outgrow it.
Alternatives are Webpack (stable, boring), Vite (starting to overtake Webpack since it's significantly simpler), and 1000 other libraries.
Again, there is some movement here, but Webpack has been in a dominant position for nearly a decade and there's no reason you can't continue to use it today if you value stability. It's the equivalent of choosing to host your backend on a VPS instead of trying out serverless.
Needing a build step is part of the complexity of frontend. I think frontend is getting much simpler with build tools like Vite and the addition of ES modules. But, even with these new things coming out, you can stick to your boring stable choices on the frontend just like you can on the backend.
Yea I'm not really buying it. create-react-app is deprecated. https://react.dev/learn/start-a-new-react-project points you directly at Next.js as a *starting point* and the section about using React without a framework does it's best to discourage you from doing it.
This is insane for beginners.
You only really need a build step to use JSX, which is strictly speaking optional.
This is true (and part of why I love React/JSX) but in practice nobody writes JSX by hand.
This is so true. Anyone trying to learn frontend as a newbie today has an unreasonably hard task at hands. So much unwarranted complexity.
I feel like the backend is just an inherently simpler problem to solve, request in, response out. Largely stateless. Of course there are harder things to do like stateful 2-way connections, but the solutions are mostly concentrated on a couple of technologies. Like yeah we have stuff like graphql, but at the end of the day the principle is the same.
"Backend" is absolutely not a simpler problem to solve, it's an umbrella term encompassing a wide variety of domains. If you're talking specifically about Web backends, then sure, maybe there's a case to be made there.
User interfaces have different, inherent complexity that backend programming doesn't have. If you look at the Android & iOS native toolkits they've churned at least as much in the same time.
Also, and it seems like this has to be pointed out in every one of these threads, the complexity of interfaces we're building on the web now is far greater than what we were building 10 years ago.
Not sure why this is downvoted without comment, many people underestimate the complexity here.
> I’ve held off on diving into front end because it’s just such a circus
Its only a circus if you're constantly chasing the new shiny thing. Many of us have been productively building apps in react for nearly a decade without significant changes in tooling.
While I don't think react is the best frontend framework, it has become the industry standard and therefore is the most peaceful approach to building apps in 2024.
This is the way
i don't know really what to do about it, but i did write a book on the ideas of hypermedia and how htmx extends them that you can read online for free here:
i think the ideas of hypermedia are fairly stable and relevant, particularly the concept of a uniform interface, even if htmx is just one implementation of them
I considered myself a frontend dev 10 years ago, I loved jQuery and Angular 1.x, Sass. I never really caught the Node fever, and it seems like almost everything connected with the JS scene since then has been constant churn and complexity. I moved into infrastructure and data and never looked back.
That said htmx is the only remotely intriguing development I've seen in frontend dev in a decade.
I too loved jQuery, we've used Vue which is on 3.x now and doesn't really seem like it will change terribly much, in the future. It solves all of the things that in jQuery became really difficult while still feeling like there is still a DOM somewhere in there and we're not all that far removed from jQuery style js. Will agree though, most of the newer frameworks I just don't get.
Many others including myself have made this observation. I think I've finally formulated why there seems to be such a stark difference between FE and BE/systems cultures.
The backend and systems programmers are still writing code in a programming language.
So much of FE dev now is stringing together other people's declarative frameworks. When programming is done it's mostly glue. So if you exist in this paradigm you're going to have very strong opinions about whatever framework/tech you are using because it's so hard to operate outside of it. You also gain a vested interest in the survival of whatever you've chosen.
This is why I've been slowly trying to make the transition out of web dev, at least FE. I don't want to deal with this crap anymore!
> then as if that wasn’t enough the whole fkin meta changes monthly. We’re doing react. No actual wasm. Wait no static page. Or maybe htmx. Or vanilla js. Or maybe a mix…well call it remix…it just never ends
Who told you to do all those changes? Maybe change who you're listening to, or even better: don't blindly follow what others say/talk about, but listen and think about it thoughtfully instead. Stay on whatever framework/library/platform you want and feel works best for you and your use cases. No one is forcing you to chase the latest trends.
True, but it does suck to have backed the wrong horse. You framework/library/platform can rot if nobody else is using it. You can't get away with just ignoring it.
It helps to pick "boring tech", and hope that what has worked will continue to work. But it's still unpleasant to hear about the X killer every week, when X is your bread and butter.
Hasn't Rails been traditional server with patched with dynamic parts since like 2005? I would pick that
I've been ignoring frameworks and focusing on mostly vanilla JS and have worked on some of the most interesting and well paying projects for 15 years now. Haven't been following any of the hype, even Typescript. Was forced to do some React/Typescript at work for the first time last year and it was fine. Was able to get up and running in a few days.
Yes, this is exactly why you choose Htmx. So you can focus on web fundamentals. Reason about HTTP and HTML. Sometimes throw in some vanilla javascript when absolutely necessary. Pull in one or two hand-picked zero-dependency libs for things like drag and drop or a nicer date-picker or something.
We have been using HTMX to create performant storefronts and the results are satisfactory.
https://farmrio.deco.site/ is one of the largest clothing retailers in Brazil and all the frontend interactions use HTMX, alongside a partial rendering strategy we developed.
More info at https://deco.cx/en/blog/htmx-first-class-support
Love how good the CLS is. I wonder if you can deal with flashes of white during navigation with the new View Transitions API
I'm not sure this is htmx's fault but I wouldn't exactly describe that as snappy
This "HTMX in React" idea just reinvented React Server Components. https://react.dev/reference/rsc/server-components
An attractive future direction might be to re-implement Htmx in React:
• The server sends a JSON blob that React converts into virtual DOM components.
• That would solve the component state problem.
• It would mean we require no special bridge to use React components.
• It would let us use our React-connected web fetching library, and carefully avoid the queuing choices made by Htmx.
• It would solve the morphdom problems and browser DOM input elements problem, too, which is pretty much a solved problem in React.
In this way, we could drop the Htmx dependency but retain the benefits of the idea. That is, given a budget to embark on such a big piece of work.
RSC is still experimental, and the default implementation assumes that you're going to run JS on the server, which undermines some of the point of HTMX.
But someday (likely in the next year or so) the RSC wire format will be standardized, and then any language can generate RSC JSON for React to consume.
> The default queuing mode is bonkers
> By default, Htmx will cancel requests that are in-flight if you trigger another request on the same queue (element).
This seems like the only default that's reasonable to me
don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input
Just processing one response after the other won't be possible if a response swaps out content with different IDs, so a second response won't be able to be swapped out in the same way
> An attractive future direction might be to re-implement Htmx in React: The server sends a JSON blob that React converts into virtual DOM components.
Isn't this exactly what HTMX was replacing? The client needing to have a ton of logic and state?
Turns out there’s good reasons to do that
That last point about dropping HTMX as a dependency but keeping the benefits is why I personally find Phoenix liveview so compelling.
Is there an equivalent to Turbo Mount for Htmx? https://evilmartians.com/chronicles/the-art-of-turbo-mount-h...
I think it's one of the best ways to use Hotwire/Turbo. Default to Hotwire to whatever degree of understanding you have, and as soon as it feels like HTMX/Hotwire isn't the right tool, you can easily switch to your framework of choice.
Very much agree with you on this - htmx (turbo, hotwire, alpine,...) are not trying to replace all your client side logic.
It's a spectrum of interactivity, and we should try to pick the best (whatever that may mean) tool possible for the job - sometimes that's hx-boosted links, sometimes it's a react app
what about using web components?
After hearing about it for years, and it apparently being popular in the Django community, I tried htmx for the first time just this morning on a very simple task in an admin interface.
It's easy to put unobtrusively in place, fun to play with, and it worked. Reminded me of using jQuery for the first time. Would I use it for a complex and involved project? Initial impressions suggest probably not.
It's jQuery but for HTML. Same spaghetti result, different language.
maybe so, but sometimes spaghetti is delicious:
> React and Htmx do not interact nicely.
I want to dig into this a bit. React of course maintains its own rendered part of the DOM and htmx trying to reach into and change any part of that DOM is not going to go over well. It's just going to be replaced with React's rendering again on the next render cycle.
htmx provides two points at which it can interact with other libraries or frameworks: DOM events and CSS classes. I don't see any problem with classes, but React's synthetic events would probably not work well with htmx (or any other non-React library really). Maybe frameworks like Preact which use real DOM events would work better.
> Even morphdom overwrites some things you’d expect it not to, so we had to patch it to avoid messing with input elements, and details elements.
Would love to hear more about this issue. Preserving the state of elements like input or detail is the main function of libraries like morphdom, something must have gone wrong there.
at the end of the day morphdom (and my own algorithm, idiomorph) can only do so much, because the current DOM APIs nuke much of the state of nodes when they disconnect from the DOM
if you look at the algorithms they give up very quickly and simply merge the new nodes in once matching doesn't work at a certain level because of this
there is a new API coming down the pipe, moveBefore(), that will allow much better morphing/preservation in general:
https://github.com/noamr/dom/blob/spm-explainer/moveBefore-e...
htmx supports it today if you enable it in chrome canary:
> Htmx-in-React?: The server sends a JSON blob that React converts into virtual DOM components.
The author should try inertia.js, it has server-side routing and react templates.
Totally disagree with state in the DOM. It’s natively where it exists.
Also in the URL. Both are totally okay, and even desirable. We’ve become so accustomed to managing state in abstractions of the DOM that this seems like a crazy idea, but it has led to all kinds of pain points from complexity to, well, the DOM and URL not always reflecting the state of the application accurately. It’s pretty awful.
The better we can keep state out of abstractions without losing maintainability or performance, the better.