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.
Narhem 9 days ago [-]
I know there are other libraries which offer similar features (alpine.js), but none are as simple and focused as HTMX.
It seems like such an elegant solution I’m surprised more people haven’t started using it. It just works.
Nathanael_M 9 days ago [-]
Man, you’re everywhere. I have a Montana’s restaurant in my city and I’m scared to go in because of you.
recursivedoubts 9 days ago [-]
you should be
dullcrisp 9 days ago [-]
By queue only one additional request, do you mean cancel any existing queued request?
recursivedoubts 9 days ago [-]
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:
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
dullcrisp 9 days ago [-]
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.
recursivedoubts 9 days ago [-]
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:
Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.
recursivedoubts 9 days ago [-]
yeah i prefer just plain ol' if statements, i find them easier to debug
jrochkind1 9 days ago [-]
I had to read and think carefully enough about what you just explained (on second try!) to feel like I understood it, so I'm not at all surprised if other people are confused about or misinterpret what they are seeing! (I'm not an htmx user though).
Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it!
I am curious to hear the reasoning/use cases for this choice being the default strategy.
dullcrisp 8 days ago [-]
It makes sense with GETs if you’re opinionated I think.
This way an in-flight request has a chance to complete (otherwise if you send requests too often none of them would ever finish), but any request that hasn’t started yet isn’t sent since it’s meant to be overwritten by the result of the later request anyway. Of course if you expect later requests to do anything other than idempotently replace the previous ones you’ll be surprised.
heavensteeth 9 days ago [-]
I cannot express the pleasure I felt seeing prices in my local currency automatically, without the Shopify "Zoinks! Looks like you're on our American store, would you like to change to our Polish store?" modal I've come to know and hate. Thanks.
troupo 9 days ago [-]
Often changing to local currency isn't just a straightforward x*(exchange rate). There could be weird taxes applied
echoangle 9 days ago [-]
And regional pricing, although maybe less relevant for hardware
nickpeterson 9 days ago [-]
I’ll definitely pile on with the inheritance causing issues. It made me feel like unsetting them constantly defensively.
recursivedoubts 9 days ago [-]
You can disable it globally, see htmx.config.disableInheritance:
the good thing about htmx / javascript or even a framework like Vue - is that the authors know the web browser is not a 'pure' platform as React people try pretend it to be.
because of the event system on the web - things yeah are weird.
And thanks for bringing intercooler.js / htmx as alternatives to a crazy world.
orangetable99 9 days ago [-]
yeah, inheritance enabled by default bit me in the ass more than once. With template engines you end up trying to debug some weird behavior and it takes some time for you to realize somewhere up in the tree on a different file there's an hx-* tag being inherited.
I should have disabled it early in the project, too late now.
I also still haven't figured out how to properly use the "save history to local storage" thing. Often there has been a server state change between the user navigating away and clicking the back button and I see no option other than disabling the thing altogether.
Havoc 9 days ago [-]
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.
shepherdjerred 9 days ago [-]
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.
Lutger 9 days ago [-]
React proper may be more or less stable since hooks came out 6 years ago, on its own it isn't sufficient. You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever. And some of these have changed radically from year to year. The react ecosystem is not stable.
It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app.
It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.
alexanderchr 9 days ago [-]
> It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app.
I've maintained a sizeable react app for 8 years, and this has not been my experience at all. Maybe 10 years ago things would break monthly but nowadays things are quite stable, with very reasonable deprecation schedules and upgrade paths. I have lots of code running that I haven't touched in 5+ years and it is not causing any problems even when I'm keeping the main parts of the appliaction up to date with modern practices.
shepherdjerred 8 days ago [-]
I’ve had a similar experience but I’m tired of fighting against popular opinion
shepherdjerred 9 days ago [-]
> react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever
You don't need any of this (aside from a bundler). That's my whole point. You can use these libraries and be on the cutting edge, or go with something simpler.
You'll have the exact same problem on the backend if you want to use a library for everything.
8 days ago [-]
__jonas 9 days ago [-]
> You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever
You really don't need any of this though, you can get super far with React alone, and the new docs on react.dev are great at explaining this and pushing this idea in my opinion.
9 days ago [-]
mattgreenrocks 9 days ago [-]
The churn in React keeps me out. I also get really suspicious of tech that spawns mini cottage industries, where there has to be a React-ified wrapper for every single thing.
Maybe in 2025. I've learned Svelte 5 and think it is pretty good for the tradeoffs it makes though. And I think MPA is the right default for 95% of sites.
jrochkind1 9 days ago [-]
I think part of the issue is that the "boring stable" choice for front-end, React, is disliked by many, and often doesn't actually seem very boring (if that means easy to understand how to do it right) or stable (if that means doens't drastically change much) to many.
WD-42 9 days ago [-]
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.
shepherdjerred 9 days ago [-]
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.
WD-42 9 days ago [-]
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.
nsonha 9 days ago [-]
You use a lot of words to respond to such a minor point. The main point is that actual "plain react" is useless. You need at least a router, some way to manage state, some way to manage style and so on. It's why nextjs is so popular, they are practically "plain react"
__jonas 9 days ago [-]
Useless is a massive exaggeration.
> You need at least a router
You only need a router if you want to build a SPA with different routes, not all web applications are that! Tons of practical React apps are just a single screen, or even embedded component.
> some way to manage state
You do not need an external library for complex state management, the React docs have some great guides on how to achieve this with plain React:
Plain CSS and the JSX style property are entirely enough for most apps.
If you are using a build tool like Vite, you can also do CSS modules for scoping styles to your React components for more complex applications.
I do agree that styling is not a strong point of React, but I don't think pulling in a dependency is necessary.
shepherdjerred 8 days ago [-]
Here’s an example of a single page React app that I wrote several years ago that requires nearly zero maintenance, is a single screen, uses Bulma for CSS, and manages state w/o an external library
It’s an app with a bunch of random components, though not really a website.
If you want an actual website with proper routing and possibly SSR and want to use “plain” React with no additional libraries you’ll have to waste a lot of time reinventing the wheel.
I just wanna vomit reading that article (which is in official docs!!!). There is a much cleaner way of managing state with just a single `useState` per component instead of bringing over some Redux dogma for some inexplicable reason:
```
const [state, dispatch] = useState()
// ...
dispatch(doThis)
dispatch(doThat)
```
__jonas 9 days ago [-]
Well of course component state is what you reach for first, which is why it is the first four sections of those docs about state management I linked:
I was linking this later section about extracting state logic into a reducer, because you suggested that you would need "something for state management", I assumed you were talking about something like redux.
But of course you can get pretty far with a single useState and prop drilling as well. Not sure how it supports your point that 'plain react is useless', it sounds like you are arguing against yourself with that comment?
nsonha 8 days ago [-]
No it's a different point, in this, I just wanna express how ridiculous the official React docs can be sometimes.
The Redux "pattern" you speak of, does nothing to manage state better than useState(). So I'm not sure why that API even exists, or why you think that is a good response to "need something to manage states".
Let's go back to that, managing state would be for example error and pending state for every async action. In react, that basic, repetitive task is a whole celebration if you just do plain. Try do do form with per-field back-end validation feedback and see how much boilerplate you need for that.
__jonas 8 days ago [-]
Alright sure, I guess I just don't understand what it is "you need" for state management then, but I don't want to get caught up in this too much, you've made your point.
I 100% agree that React is super boilerplate heavy, a lot of things are indeed 'a whole celebration', I personally choose something like Svelte over React if I have the choice, because I don't enjoy that either.
All I'm saying is that plain React is not useless! It's completely fine.
I don't mind working with it, it makes a tradeoff of being more ceremony but perhaps less magic and I think the tradeoff is okay.
ywvcbk 8 days ago [-]
Now store all of those states in an URL or some other place that would allow you to recreate the full view after the website is reloaded or in a new session.
chrisweekly 9 days ago [-]
CRA is dead. Vite has emerged as its successor.
agos 9 days ago [-]
FYI, create-react-app is basically abandoned since two years. Maybe it still works but if there's any bug, good luck
roywiggins 9 days ago [-]
You only really need a build step to use JSX, which is strictly speaking optional.
Lutger 9 days ago [-]
Technically you don't even need react, you can do it all in javascript!
Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think.
If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away.
In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years.
For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things.
Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
shepherdjerred 9 days ago [-]
This is true (and part of why I love React/JSX) but in practice nobody writes JSX by hand.
cowoder 9 days ago [-]
Isn't it the other way around, nobody writes React by hand they all use JSX?
shepherdjerred 9 days ago [-]
You're right :)
aprdm 8 days ago [-]
You don't need a build step if you do everything in javascript without jsx. I have done it like that in the past on air gapped environments (and vendored the deps)
zonethundery 9 days ago [-]
I think the responses to your comment show the whirlwind of 'wtf?' confronting any programmer contemplating front end development for the first time.
What you wrote is probably true (and the one "see how far you can get in react only" comment is probably a decent path, but the landscape is overwhelming.
LegionMammal978 9 days ago [-]
Yeah, the frontend scene definitely suffers from hype-driven development: it's not good enough that we have a tool to do the job, we need the tool to be the bestest ever on every possible metric, so we end up with a treadmill of additional frameworks, bundlers, etc. that are hyped up in any given year.
E.g., I might think to ask, "Which tool creates the output with the lesser overhead on the client, Webpack or Vite?" But I can't find anything solid about that, since everyone's too busy hyping up the dev experience or whatever.
It's a shame that you have to swim against the tide so heavily, if you value simplicity over immediate kitchen-sink levels of functionality. Personally, I've landed on pure client-side React (with any bundler, or with Babel alone if you're feeling adventurous) since it doesn't try to have any purpose other than updating components according to state. Many of its competitors have too much poorly-documented magic for my taste.
WD-42 9 days ago [-]
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!
mattgreenrocks 9 days ago [-]
Webdev is a different culture for sure. I think it brings a lot of newer devs in, which is fine, but then their lack of experience makes them vulnerable to groupthink, choosing easy over simple, demagoguery ("it's different this time!" seems true if you don't have prior experience) and needing to jump to the newest flashy thing. I'd also argue that this shift implicitly devalues the actual building of things (which is hard to assess and requires expertise) in favor of social clout (which is easy to assess), but this could just be coincidental with the rise of social media. Regardless, there is brand-building you can do and people routinely conflate social clout with technological prowess.
I gave up on webdev when this started to set in. Honestly, it felt like a bunch of kids chasing thoughtful engineering out by simply making more noise. Everyone wanted a magic library that relieved them of thinking, but the only way to make decent software is to think deeply about what data flows where, and how it gets there.
I've since rekindled an interest in it after finding some tech that did click with me: Quarkus + Renarde, htmx, Svelte. All of these are off the beaten path and have users that choose to use them, versus those that have to do, and I really think it makes a difference.
> This is why I've been slowly trying to make the transition out of web dev, at least FE.
Systems/backend dev is a lot more friendly to thoughtful engineering IMO. Check out Java, Golang, and Rust and see what libraries/users you click best with.
stephenhuey 9 days ago [-]
Pretty cool, I hadn't heard of Renarde and it looks promising. Around 8 years ago, I really wanted Aurelia to win the SPA wars but they're still pretty niche even though they've been growing lately. But honestly, after playing with everything over all these years, I still believe a server-side framework with minimal amounts of JS is ideal for most projects, especially all those internal corporate web apps but also for B2B stuff and even the average consumer-facing app. People say consumers are more demanding now, but how many developers are really working on something that caters to the most demanding consumers? Unless you need the most snazzy UX ever, just don't.
And honestly, using Rails or other server-side frameworks, you can get very far with way less effort than those expensive front-end teams by simply using Hotwire:
Sending down rendered HTML using Hotwire Turbo requires far less time, and HTML over the wire is in reality no heavier than sending down JSON. If you absolutely need a bit more interactivity on the front-end while avoiding a server roundtrip, it's easy to drop in little Stimulus JS controllers as-needed. From my journeys to and fro in the real world, I've seen most projects do not need more than that, and are arguably wasting budget trying to use heavier tools than that! For most sizeable projects, you can do more in Rails & Hotwire with fewer developers than a 6-person team using their favorite server side language and React. I'm not saying you have to use Ruby on Rails. I'm saying I wish the dev world would embrace this paradigm in whatever their favorite language/frameworks are.
fnordlord 9 days ago [-]
Beware that backend has plenty of those declarative frameworks also... Kubernetes, terraform, most CI environments, CMake. (I'd add SQL but since it's the only one that doesn't drive me crazy, I don't like to think of it as declarative)
I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."
mattgreenrocks 9 days ago [-]
> Beware that backend has plenty of those declarative frameworks also
Thankfully, they don't take over your application code, though they eat a considerable amount of brainspace, especially in the collective discourse.
Discretion and focus remain key skills in tech these days.
jrochkind1 9 days ago [-]
I don't know, I'm a backend programmer myself (although I dabble in front-end, and indeed, don't love it), but "the frontend programmers aren't really writing code in a real programming language" claim just sounds like an old greybeard writing in assembley complaining about how programmers that don't know and write in assembley are lazy and don't really know how to program. Iterate and repeat with every new development technology.
Don't get me wrong, the front-end certainly seems like a mess to me too. Although I think it's actually not quite as bad as it used to be, maybe over the hump one can hope.
jerf 9 days ago [-]
Backend code lives together better too. It's trivial for me to set up a frontend web server that points one URL to a handler in Python, another in Go, another in Java, and whatever else I like. Said frontend can also do a lot of useful abstraction over things like login and authentication, and even to a limited extent authorization. Backend does not compose perfectly but it composes together reasonably well. This architecture may be problematic for other reasons, but it isn't intrinsically a huge problem right out of the gate.
Frontend, you largely have to pick a team. Trying to run multiple frontends in the same page has a number of problems, if nothing other than each of them gets so large that even just one can impact performance, but they will also fight over events, and you can't cross the streams, etc. The whole structure is more winner-take-all, by its nature.
wpietri 9 days ago [-]
Ah, this makes a lot of sense to me. Thank you.
Interestingly, I think this problem exists in areas of back-end work. I know people who mostly do systems integration, where they're customizing some enterprise behemoth. But since that world is anchored both by the big vendors and by your company's choices of them, it seems saner to me. People may identify as a SAP developer or whatever, but they don't have to advocate for it or have a quasi-religious belief in it.
confidantlake 9 days ago [-]
Backend, the land of no frameworks. Not a Rails, Django, Spring, or Laravel in sight!
papruapap 9 days ago [-]
I see BE coding more and more in configuration files nowadays YMMV.
cageface 9 days ago [-]
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.
gyomu 9 days ago [-]
I have UIKit (iOS) code that’s over a decade old and still compiles and runs perfectly (it might look a bit off on new hardware form factors - eg content bleeds into the notch - but that’s about it).
I have Python + Tkinter code that’s close to two decades old and still runs great (doesn’t look great tho but it didn’t look great at the time either).
I have some vanilla JS websites that are about as old and still work great.
As other commenters have noted, boring stable choices are there. Ignoring them for the fancy novel brittle stuff is entirely on the programmer.
arvinsim 9 days ago [-]
I bet all of your examples are not something you deploy to a modern application today.
All of those are good in theory but don't stand against the demands of modern consumers.
gyomu 9 days ago [-]
Bet lost.
If as a technologist you can’t imagine companies making money selling software to happy customers without relying on the brittle trendy framework du jour, my only advice would be to spend less time making silly bets with strangers on internet discussion boards and more time looking at boring profitable companies.
arvinsim 8 days ago [-]
Of course, because everyone is a freelancer who can just choose what technology they can use to work on, right?
You sincerely believe that devs will just add complexity to their work just because?
mattgreenrocks 9 days ago [-]
A lot of devs justify the time they spend keeping up with the technological Joneses as necessary to keep pace with current trends (especially in UI). I think it is a bit of a cope though, because users just want to solve their problems.
They don't care about React or htmx. They just want something that fixes the problem.
This is actually very freeing: meet a real need and you don't have to believe that software development consists on running on a treadmill of constant changes for their own sake. Just do the job competently.
arvinsim 8 days ago [-]
We don't live in a world where every dev can choose the technology they work on.
Most of the time it is dictated by the whims of corporate(by making frameworks/tools as part of a job requirement) or by the mob(teams need to collective decide what technology to use).
seanhunter 9 days ago [-]
It must be very tiring to keep up with the demands of all modern consumers. There are so many of them, and they are so different from each other.
Meanwhile when I go out in the world I see all manner of front-ends being actively used. It's almost like different users want different things idk.
mrbombastic 9 days ago [-]
Not sure why this is downvoted without comment, many people underestimate the complexity here.
kitsune_ 9 days ago [-]
There indeed is complexity, but a lot of the projects that are created to deal with that complexity that gain traction are made by people who don't have much experience in general, or lack exposure to non-frontend programming, so you end up having to deal with a lot of half-baked stuff. It's kind of a lethal cocktail.
skydhash 9 days ago [-]
Ui is practically a problem solved (from the technical perspective). The complexity you’re talking about stems from trying to solve the problem with the wrong technology (the DOM). Laying out text for a document is fundamentally different from creating an application interface. An things that are easy to do in any UI toolkit (from GTK to Android) can only be hacked in the DOM. Things like layout constraints (between two components) and lists.
recursivedoubts 9 days ago [-]
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
eddd-ddde 9 days ago [-]
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.
shadow28 9 days ago [-]
"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.
arvinsim 9 days ago [-]
Which is why it puzzles me that the "frontend devs are not real programmers" meme still exists. Like if it is so easy, then why can't backend devs do it themselves?
backbeginning 9 days ago [-]
We can, management just insists on hiring JS kids to do it a thousands times more complicated. "Just use a sane PHP framework" will get you fired now. Alas.
The problem is thinking that all of these things are different domains when they really aren't. The web browser is just a program; its job is to fetch resources and render HTML. If you know how HTTP and HTML/CSS work, you can absolutely make great web applications.
But this requires knowledge and expertise, and also maybe not shoehorning an entire application framework into what was designed to be a collection of hyperlinked documents. I suspect this has more to do with money than anything else... the web is dead, long live the web.
skydhash 9 days ago [-]
Complex tasks are different from complex tools.
Jgrubb 9 days ago [-]
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.
91bananas 9 days ago [-]
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.
confidantlake 9 days ago [-]
Saying you love Angular 1.x while complaining about complexity is an interesting take.
palmfacehn 9 days ago [-]
IE is dead, document.querySelector and friends are sufficient where jQuery was needed. Instead of basking in this achievement, frontend tooling has heaped on bloated build steps with thousands of dependencies. According to the current trends this is the standard way to populate a dynamically updated table or serve a static landing page.
sensanaty 9 days ago [-]
How people don't get bored of this same exact thread in every single one of these posts is beyond me.
But also as someone who does fullstack in a pretty much even 50/50 split, this is such a tired meme by this point seemingly from people who just refuse to actually sit down and think about the FE ecosystem for longer than 3 seconds and end up parroting this same talking point.
You could make a similarly dramatic post about the backend world. There you're even fighting which programming language you want to pick. PHP, Ruby, Go, Elixir/Erlang, C#? What about the recent mess with ElasticSearch and Redis? Where and how do you host your backend? Which DB do you use and why? Mongo, anyone?
At this point in the FE framework world, you've got 3 very stable players that have been there for a decade. Angular, React and Vue. And sure, they've each gone through some sort of reworks in the past, but nobody's forcing you to pin your dependencies `@latest`, you can pretty much always keep trucking along with whatever version you were on. We've got a huge app still running along on Vue 2 (not even 2.7 which backports the very nice Composition API) and we see no reason to bump versions to 3. I've even had some nightmare scenarios trying to update Rails and Laravel in the past that dwarf any problems I ever encountered in the frontend world.
Also, vanilla JS, HTML and CSS still exist and work just fine if you're building some small toy thing, but you'll quickly realize why these frameworks exist in the first place (or you'll do the dumb thing of building your own as some do) if you're doing anything more complex than a brochure website.
And the tooling has only gotten simpler if anything with Vite. Want to start a new frontend project? It's literally just `npm create vite@latest`, and you get a nice TUI with which you get to fully customize what you want and don't want. The README even comes with a nice little list of commands for you to run, and hosting can be done literally anywhere where you can deploy the `dist/` folder to, just like the "good" old days.
For people who always claim superiority for being the genius backenders they are, they sure seem to be having a lot of trouble with something that they will themselves say any coding monkey coming out of a bootcamp can do with relatively few problems.
teqsun 9 days ago [-]
As a fellow full-stack I agree.
There's a joke I've told many times in interviews if they ask me to define what a full-stack engineer is, to which I joke "It means I do whatever the senior engineer doesn't want to do, which 99% of the time is front-end". The people I tell it to laugh, because it's funny but also because it's true.
On the front-end you're dealing with more customer/users and it's inherently more of a servile role, while it's much easier to be stubborn, eccentric, 'powerful' in the tech-facing backend.
I'd also wager there's a certain "tech purity" angle too, given the inherent reverence foisted upon lower level languages and programming fields that is seemingly rife.
To play devil's advocate on myself, perhaps it's more that the higher end technical complexity challenges for Front-End aren't commonplace enough. I've had the fortune to work in a field where the level of necessary technical complexity on the front-end part of my job is very high, so ymmv
confidantlake 9 days ago [-]
For real. React or superObscureFrameworkSixPeopleUseFrom2009? The churn is endless!
In the Java world alone: Spring vs EE vs Play vs Quarkas vs Micronaut vs Helidon... Tomcat vs Jetty vs Netty... Jar vs War vs Ear ... Maven vs Gradle vs Ant...
diggan 9 days ago [-]
> 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.
jfengel 9 days ago [-]
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.
colordrops 9 days ago [-]
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.
rjh29 9 days ago [-]
Hasn't Rails been traditional server with patched with dynamic parts since like 2005? I would pick that
squidsoup 9 days ago [-]
> 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.
WD-42 9 days ago [-]
React how though? Are you raw-doggin React.CreateElement? Doubt it.
So qualify "building apps in react" with whatever bespoke build system, router, state management, etc combination you are actually using.
Just because you found yourself a tent inside the circus doesn't mean it's not a circus.
arvinsim 9 days ago [-]
How is that any different from using Django in Python? Laravel in PHP land?
ywvcbk 8 days ago [-]
Django is quite stable and monolithic. If you used it 10-15 years ago and wanted to build something new it wouldn’t take too much time for you to readjust. With JS you’d be entering a new world and chances are that almost everything you can remember is now an “anti-pattern” and starting on a clean slate might be easier..
Frontend is a mishmash of random components and packages, unless you are 100% sure in advance what are you going to use and and do chances are that you’ll run into with issues with the latest version of package X not working with build system Y due to cryptic incomprehensible reasons unless you make sure to stick with the latest “mainstream” trends (which seem to change ever 1-2 years).
squidsoup 8 days ago [-]
> Frontend is a mishmash of random components and packages
You could say the same about developing in Clojure, or Rust or Golang, but somehow you typically only see this same tired rhetoric applied to JavaScript.
lenkite 6 days ago [-]
No, you cannot say the same about Clojure and Golang. Those are extremely stable languages. Go lang esp has a batteries operated standard library that can be used to develop apps with excellent backward compatibility - you can get back years later, upgrade the runtime and build and deploy your project - and it will work without issues. The comfort you get is soothing. The same is certainly NOT true of JS where stuff breaks from month to month, build paradigms change yearly - causing severe amounts of deep stress.
The rhetoric applied to JS is fully valid and justified.
squidsoup 3 days ago [-]
The philosophy of building apps with discrete libraries that do one thing well absolutely applies to js, clojure and golang. I have no idea what you’re referring to when you say things break month to month, that has not been my experience with js. Regarding paradigms changing yearly, also not true - have been building jsx apps for a decade and the only significant change has been from class based components to hooks, which was an easy and welcome transition.
Things also change in all language ecosystems. Does anyone use lein these days? Not really.
squidsoup 8 days ago [-]
Have generally favoured picking the most boring and popular tools. Used CRA for many years, and then switched to vite for builds. Vite is essentially the industry standard and painless to adopt.
React router for routing, since.. as long as I can remember.
This notion that the ground is constantly shifting beneath you just hasn't been true for over a decade.
ywvcbk 8 days ago [-]
Every few years I end up wanting to build some random/hobby webapp and each time the official docs have changed drastically.
Use CRA + webpack, now use Vite instead, you know what? Screw CRA you should just immediately jump to Next.js instead (which seemed like a huge overkill initially, but actually seems kind of nice).
Unless you’re working on a single project or continuously following what’s new it just seems confusing and overwhelming. If I got comfortable with CRA and came back after a year or two should I still use it for a new project even if it’s bo longer the default? Will new packages/etc. still work with it? Maybe… who knows. I just know that I now have to waste time figuring that out.
When React "is just a library" but the installation instructions tell you to install some large, VC-backed framework immediately - it just doesn't sit right with me.
squidsoup 8 days ago [-]
That is an absolutely fair criticism - it’s unfortunate that vercel has so much influence over the future of react.
squidsoup 8 days ago [-]
It takes five minutes to bootstrap a new react project in Vite or Next. You are significantly exaggerating how hard this all is.
ywvcbk 6 days ago [-]
I’m not saying that part is hard or particularly relevant. It takes a lot more time than 5 minutes to figure out how the new framework and/or build system works and all the implications of that, though.
andyp-kw 9 days ago [-]
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.
klysm 9 days ago [-]
This is the way
stephenhuey 9 days ago [-]
I entered the working world in the aftermath of the dotcom bust when JS was a nightmare of footguns (much more than now) and Microsoft literally had zero developers working on IE, the most-used browser in the world, for YEARS. Web dev was therefore stuck in an archaic prison and there was much rejoicing the day Microsoft announced they were once again assigning a team of developers to work on the browser. Fast forward a decade and a lot of terrible things in JS were being rectified at the language level. A dozen years ago, I tried a SPA for the first time and it seemed cool to have a framework (Angular, the first version) to provide more abstractions than jQuery and Backbone. However, the groupthink bandwagony insanity that ensued was ridiculous, and I felt like such an old codger trying to tell the kids to just be grateful that JS was finally working pretty well and move on and build stuff instead for a while instead of spending so much energy remaking the tools every 5 weeks. I'm not trying to be dramatic--I really do feel like companies have no idea how much they overspent on web app development in the past decade versus how much more working code they could've gotten for the money they spent. It literally felt like people were creating extra work, and had no idea how much easier it was than a few years before.
wvbdmp 9 days ago [-]
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.
wg0 9 days ago [-]
You should then look at the circus that is CJS and ESM compatibility [0]
My preferred way of writing frontend code is ClojureScript with Reagent. That hasn't changed in eight years since I discovered Reagent eight years ago.
Just don't chase fads. Stick to things that you know are working fine.
draw_down 9 days ago [-]
[dead]
lucis 9 days ago [-]
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.
The example on the blog post is one of those that makes me severely question HTMX and the stuff that we're doing. Doing HTTP requests to increase a counter, or affecting any local-only state change at all, seems so wild to me.
karmarepellent 9 days ago [-]
It makes me question what we are doing too. I'm using HTMX extensively at work, but I never use it to only update local state. A few lines of Javscript on the client will do that.
However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0].
Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set.
It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX.
“Counter app” is basically “hello world”, not how best practice is conveyed.
If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API).
No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
Tabular-Iceberg 6 days ago [-]
What’s the use case for a counter that doesn’t update the backend?
For example a like counter wouldn’t be much good if nobody else can see your like.
boredtofears 9 days ago [-]
I'm not sure this is htmx's fault but I wouldn't exactly describe that as snappy
heavensteeth 9 days ago [-]
I thought that too, but whole page loads are slow too; I assume it's just because I live nowhere near Brazil.
lelandfe 9 days ago [-]
Love how good the CLS is. I wonder if you can deal with flashes of white during navigation with the new View Transitions API
lelandfe 9 days ago [-]
Oh, it's because the site does `*{visibility:hidden}` during loading. Don't do that, show us the intermediate state >:)
You're artificially making your FCP also be your TTI, which means page navigation, when everything should be cached and fast, feels slow. That's not something e.g. Lighthouse tells you.
I recommend showing the page right away, even if there's going to be jank. Jank/Cumulative layout shifts can be fixed later.
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.
sauercrowd 9 days ago [-]
> 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
naasking 9 days ago [-]
> 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
If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.
sauercrowd 9 days ago [-]
This won't work
if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI
naasking 8 days ago [-]
There are many choices here, such as never setting outerHTML but only innerHTML/nested content. Also, "processing responses in order" doesn't necessarily mean "immediately mutate DOM for each response", eg. defer if there are in-flight requests and aggregate changes. htmx arguably gives you too much flexibility which is why there are no straight answers that work for all scenarios.
stavros 9 days ago [-]
> 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?
klysm 9 days ago [-]
Turns out there’s good reasons to do that
nsonha 9 days ago [-]
Only veteran web devs are able to come up with such a bonker idea that not managing state explicitly is somehow better. That's just basic programming but I guess they don't need that to write html.
NoGravitas 9 days ago [-]
Yeah, a lot of the article was reasonable, talking about implementation details they don't like, but once they started talking about problems with local state I feel like they went off the rails. The server needs to be the source of truth for application state, with the application pushing state changes through POST/PUT/DELETE requests.
stavros 9 days ago [-]
I agree, no matter how much we don't like reloads, the fact that they reset your whole client state makes things much simpler.
jasoncartwright 9 days ago [-]
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.
candiddevmike 9 days ago [-]
It's jQuery but for HTML. Same spaghetti result, different language.
Reading the complaints about state makes me think the author has never built websites prior to things like react existing.
The examples don’t even make sense, it just sounds like someone trying to use htmx like it’s react and then getting upset cos it doesn’t work how he expect it to. Lack of experience.
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.
sauercrowd 9 days ago [-]
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
pier25 9 days ago [-]
what about using web components?
ricardobeat 9 days ago [-]
> 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.
recursivedoubts 9 days ago [-]
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:
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.
Daril 9 days ago [-]
Before HTMX I used Turbo Hotwired and Unpoly.
From my very personal and pragmatic point of view (I am a lone developer : I need to create software solutions that are robust and that simply work without the need to spend months to learn a new technology, that probably will be replaced by a new one in two months or so, that no customer is willing to pay), HTMX is the most pragmatic and useful solution.
It is complete in features and you can do literally anything with it and is easy to integrate in existing web applications.
I used it with CodeIgniter and now with Golang.
can3p 9 days ago [-]
Local state is indeed a problem that's exacerbated by swapping logic. Simple example: you have a form + a collapsible block inside or maybe a dynamic set of inputs (imagine you're adding items to a catalog and you want to allow to submit more than one). If you save the form and simply swap the html the block state will be reset. Ofc you could set the toggle state somewhere to pass it along to the backend, but that's a pain already compared to spa approach where you don't even bother with that since no state is reset.
You could you query string as mentioned in the article, but that's not really convenient when done in a custom way for every single case.
Having said that I think that a way to go could be a community effort to settle on the ways to handle different ui patterns and interactions with some bigger project to serve as a testing ground. And that includes backend part too, we can look at what rails does with turbo
My opinion is that htmx (and similar) approach is different enough to potentially require a different set of ui interactions and it usually hurts when one tries to apply react friendly interactions to it.
reidjs 9 days ago [-]
I set up HTMX for a toy project recently, seemed fine to me. I think the philosophy of HTMX is the real selling point, sending structured content instead of passing JSON around. There is an opportunity here to either improve HTMX or build a competitor.
chromanoid 9 days ago [-]
For the record with https://hotwired.dev there is already a rather successful "competitor".
"HTMX in React" seems to be a very complicated idea. Seems to me like Vaadin territory in terms of complexity. I think you have to embrace the MPA approach otherwise you will not be happy with any MPA technology.
novoreorx 8 days ago [-]
The "HTMX in React" idea seems like the author intended to offer some insightful thoughts after criticizing HTMX extensively. However, it comes across as somewhat amateurish and appears to be created mainly to demonstrate an objective attitude.
begoon 9 days ago [-]
Has anyone used htmx for a more or less large project?
Everything turns into spaghetti code really quickly.
Separation of API and frontend isn’t just for fun. It’s for making testing bearable.
Finally, mixing data modelling (database) with presentation (html output) in one place (htmx handler) goes out hand really quick too, making testing much harder.
But real coding cowboys from the golden age don’t write tests, right? :-)
NoGravitas 9 days ago [-]
Depending on what you mean by large, I have. Testing is just the same as on any server-side MVC application. And I don't get spaghetti, because the structure is provided by the backend framework. Same with the data modelling - there's a model layer in the backend project that can be tested independently of everything else.
I can only guess that you're trying to put all your logic and structure on the front-end, with the backend only serving what the front-end needs ad-hoc? Don't do that. Build a classic MVC app (Django, Rails, ASP.NET MVC), factor your views into small, reusable components, and use HTMX to replace page elements at that level.
hu3 9 days ago [-]
I have, using htmx before htmx existed.
Similar concept and functionality. jQuery plugin attach events like "x-post" and other attributes, sends data to server which always returns HTML.
800+ CRUD pages full of business logic, around 2k routes, single PHP server, single MySQL server, serves up to 3k requests per second seasonally, P95 around 50ms.
Team still adding and changing features every 2 weeks, even after years in production. Stack is custom PHP framework, MySQL, custom jQuery plugin that acts similar to htmx.
Onboarding is dead easy. It was made with a no-build frontend stack. Meaning there's no build pipeline to understand and fight against.
I look at React/SPA misuses and self inflicted pain, and feel sorry for them.
9 days ago [-]
manchmalscott 9 days ago [-]
That last point about dropping HTMX as a dependency but keeping the benefits is why I personally find Phoenix liveview so compelling.
dartos 7 days ago [-]
I really like elixir, but I don't think i like live view.
Handling events by writing functions that need to match unchecked strings feels _super_ clumsy to me.
I know elixir processes are very very cheap, but I still don't like the idea of maintaining a stateful connection for each live view page, especially with the lack of typing.
Jumping between my markup and the 10s of different handlers in my live view is annoying too. I like the locality of behavior principal a lot.
Again, I really like elixir, but untyped languages kind of suck for dealing with the string based world of web frontends. That's why so many javascript shops take on the complexity of typescript.
manchmalscott 6 days ago [-]
Given that the event names are passed as attributes on the html elements themselves, they’re pretty limited to being strings. I don’t know how else it would be done.
dartos 6 days ago [-]
I don’t know how either, but it still feels clumsy.
ipnon 9 days ago [-]
Yes, I'm all in on Phoenix and LiveView because of this.
9 days ago [-]
anentropic 9 days ago [-]
> 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.
I don't understand what is left of HTMX if you do this.
Isn't that just React?
nprateem 9 days ago [-]
For state, just create a container with x-data and use alpine, then let htmx replace the content. Works pretty well, but you can end up with needing some events which are a mess to keep track of.
No use if you want react though...
dartos 9 days ago [-]
I’m going full stupid into HTMX.
I’m building a thing with HTMX and hyperscript. Very excited to run into these issues for myself.
dsego 9 days ago [-]
> 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.
WesolyKubeczek 9 days ago [-]
Superficially, the cure the article is proposing smells way worse than the poison: implement htmx in React.
I don’t know, maybe it really solves their problem, but it just feels so… wrong. I don’t know. (Shakes head, gesticulates, exits the scene)
andrewmcwatters 9 days ago [-]
Totally disagree with state in the DOM. It’s natively where it exists.
steve_adams_86 9 days ago [-]
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.
Or the part where you use data tags for something that should be done with JSON...
naasking 9 days ago [-]
Why "should" it be done with JSON?
rrgok 9 days ago [-]
What are the other ways? XML inside the attribute value or splitting up in a bunch of data attributes?
naasking 9 days ago [-]
Well it's hard to say because the OP didn't actually specify what state he's storing with JSON. Given we're talking about HTMX, all durable state should be server-side and client-side state should be generated by the server to round-trip back to the server, so it's not really clear why JSON should should be used here. Typically in this context, state is stored server-side, or client-side in input fields or in the URL as parameters (HATEOAS).
JodieBenitez 9 days ago [-]
Comments about HTMX vs. React keep popping up, but I think they miss the point and it's probably a "marketing" problem on HTMX side if people feel the need to write these.
On the contrary, Unpoly -which shares similarities with HTMX but is probably more high level- makes it very clear on its front page:
Progressive enhancement for HTML
Get powerful new HTML attributes to build dynamic UI on the server.
Works with any language. Gracefully degrades without JavaScript.
Granted, HTMX has "high power tools for HTML" right on its front page, but it also has "reduced code base sizes by 67% when compared with react".
Anyway, as always, tools ad trade-offs...
9 days ago [-]
teqsun 9 days ago [-]
I don't have anything personally against htmx, but the general sentiment I've seen tossed around about it has led me to believe that some real hellmesses are going to be calcified in it by "IDGAF about the FE" devs which will inevitably be foisted upon some poor intern to "improve".
wetpaws 9 days ago [-]
As a former PHP dev it's fun to see people reinventing the same wheels and hitting the same pitfalls industry solved 2 decades ago.
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:
https://swag.htmx.org/products/htmx-sucks-mug
Although that may be because you have a background of Industrial Engineering.
It seems like such an elegant solution I’m surprised more people haven’t started using it. It just works.
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
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...
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:
could just be: Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it!
I am curious to hear the reasoning/use cases for this choice being the default strategy.
This way an in-flight request has a chance to complete (otherwise if you send requests too often none of them would ever finish), but any request that hasn’t started yet isn’t sent since it’s meant to be overwritten by the result of the later request anyway. Of course if you expect later requests to do anything other than idempotently replace the previous ones you’ll be surprised.
https://htmx.org/docs/#inheritance
because of the event system on the web - things yeah are weird.
And thanks for bringing intercooler.js / htmx as alternatives to a crazy world.
I should have disabled it early in the project, too late now.
I also still haven't figured out how to properly use the "save history to local storage" thing. Often there has been a server state change between the user navigating away and clicking the back button and I see no option other than disabling the thing altogether.
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.
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.
It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app.
It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.
I've maintained a sizeable react app for 8 years, and this has not been my experience at all. Maybe 10 years ago things would break monthly but nowadays things are quite stable, with very reasonable deprecation schedules and upgrade paths. I have lots of code running that I haven't touched in 5+ years and it is not causing any problems even when I'm keeping the main parts of the appliaction up to date with modern practices.
You don't need any of this (aside from a bundler). That's my whole point. You can use these libraries and be on the cutting edge, or go with something simpler.
You'll have the exact same problem on the backend if you want to use a library for everything.
You really don't need any of this though, you can get super far with React alone, and the new docs on react.dev are great at explaining this and pushing this idea in my opinion.
Maybe in 2025. I've learned Svelte 5 and think it is pretty good for the tradeoffs it makes though. And I think MPA is the right default for 95% of sites.
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.
This is insane for beginners.
> You need at least a router
You only need a router if you want to build a SPA with different routes, not all web applications are that! Tons of practical React apps are just a single screen, or even embedded component.
> some way to manage state
You do not need an external library for complex state management, the React docs have some great guides on how to achieve this with plain React:
https://react.dev/learn/scaling-up-with-reducer-and-context
> some way to manage style
Plain CSS and the JSX style property are entirely enough for most apps. If you are using a build tool like Vite, you can also do CSS modules for scoping styles to your React components for more complex applications. I do agree that styling is not a strong point of React, but I don't think pulling in a dependency is necessary.
https://better-skill-capped.com/
If you want an actual website with proper routing and possibly SSR and want to use “plain” React with no additional libraries you’ll have to waste a lot of time reinventing the wheel.
I just wanna vomit reading that article (which is in official docs!!!). There is a much cleaner way of managing state with just a single `useState` per component instead of bringing over some Redux dogma for some inexplicable reason:
```
const [state, dispatch] = useState()
// ...
dispatch(doThis)
dispatch(doThat)
```
https://react.dev/learn/managing-state
I was linking this later section about extracting state logic into a reducer, because you suggested that you would need "something for state management", I assumed you were talking about something like redux.
But of course you can get pretty far with a single useState and prop drilling as well. Not sure how it supports your point that 'plain react is useless', it sounds like you are arguing against yourself with that comment?
The Redux "pattern" you speak of, does nothing to manage state better than useState(). So I'm not sure why that API even exists, or why you think that is a good response to "need something to manage states".
Let's go back to that, managing state would be for example error and pending state for every async action. In react, that basic, repetitive task is a whole celebration if you just do plain. Try do do form with per-field back-end validation feedback and see how much boilerplate you need for that.
I 100% agree that React is super boilerplate heavy, a lot of things are indeed 'a whole celebration', I personally choose something like Svelte over React if I have the choice, because I don't enjoy that either. All I'm saying is that plain React is not useless! It's completely fine. I don't mind working with it, it makes a tradeoff of being more ceremony but perhaps less magic and I think the tradeoff is okay.
Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think.
If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away.
In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years.
For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things.
Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
What you wrote is probably true (and the one "see how far you can get in react only" comment is probably a decent path, but the landscape is overwhelming.
E.g., I might think to ask, "Which tool creates the output with the lesser overhead on the client, Webpack or Vite?" But I can't find anything solid about that, since everyone's too busy hyping up the dev experience or whatever.
It's a shame that you have to swim against the tide so heavily, if you value simplicity over immediate kitchen-sink levels of functionality. Personally, I've landed on pure client-side React (with any bundler, or with Babel alone if you're feeling adventurous) since it doesn't try to have any purpose other than updating components according to state. Many of its competitors have too much poorly-documented magic for my taste.
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!
I gave up on webdev when this started to set in. Honestly, it felt like a bunch of kids chasing thoughtful engineering out by simply making more noise. Everyone wanted a magic library that relieved them of thinking, but the only way to make decent software is to think deeply about what data flows where, and how it gets there.
I've since rekindled an interest in it after finding some tech that did click with me: Quarkus + Renarde, htmx, Svelte. All of these are off the beaten path and have users that choose to use them, versus those that have to do, and I really think it makes a difference.
> This is why I've been slowly trying to make the transition out of web dev, at least FE.
Systems/backend dev is a lot more friendly to thoughtful engineering IMO. Check out Java, Golang, and Rust and see what libraries/users you click best with.
And honestly, using Rails or other server-side frameworks, you can get very far with way less effort than those expensive front-end teams by simply using Hotwire:
https://hotwired.dev
Sending down rendered HTML using Hotwire Turbo requires far less time, and HTML over the wire is in reality no heavier than sending down JSON. If you absolutely need a bit more interactivity on the front-end while avoiding a server roundtrip, it's easy to drop in little Stimulus JS controllers as-needed. From my journeys to and fro in the real world, I've seen most projects do not need more than that, and are arguably wasting budget trying to use heavier tools than that! For most sizeable projects, you can do more in Rails & Hotwire with fewer developers than a 6-person team using their favorite server side language and React. I'm not saying you have to use Ruby on Rails. I'm saying I wish the dev world would embrace this paradigm in whatever their favorite language/frameworks are.
I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."
Thankfully, they don't take over your application code, though they eat a considerable amount of brainspace, especially in the collective discourse.
Discretion and focus remain key skills in tech these days.
Don't get me wrong, the front-end certainly seems like a mess to me too. Although I think it's actually not quite as bad as it used to be, maybe over the hump one can hope.
Frontend, you largely have to pick a team. Trying to run multiple frontends in the same page has a number of problems, if nothing other than each of them gets so large that even just one can impact performance, but they will also fight over events, and you can't cross the streams, etc. The whole structure is more winner-take-all, by its nature.
Interestingly, I think this problem exists in areas of back-end work. I know people who mostly do systems integration, where they're customizing some enterprise behemoth. But since that world is anchored both by the big vendors and by your company's choices of them, it seems saner to me. People may identify as a SAP developer or whatever, but they don't have to advocate for it or have a quasi-religious belief in it.
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.
I have Python + Tkinter code that’s close to two decades old and still runs great (doesn’t look great tho but it didn’t look great at the time either).
I have some vanilla JS websites that are about as old and still work great.
As other commenters have noted, boring stable choices are there. Ignoring them for the fancy novel brittle stuff is entirely on the programmer.
All of those are good in theory but don't stand against the demands of modern consumers.
If as a technologist you can’t imagine companies making money selling software to happy customers without relying on the brittle trendy framework du jour, my only advice would be to spend less time making silly bets with strangers on internet discussion boards and more time looking at boring profitable companies.
You sincerely believe that devs will just add complexity to their work just because?
They don't care about React or htmx. They just want something that fixes the problem.
This is actually very freeing: meet a real need and you don't have to believe that software development consists on running on a treadmill of constant changes for their own sake. Just do the job competently.
Most of the time it is dictated by the whims of corporate(by making frameworks/tools as part of a job requirement) or by the mob(teams need to collective decide what technology to use).
Meanwhile when I go out in the world I see all manner of front-ends being actively used. It's almost like different users want different things idk.
https://hypermedia.systems
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 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.
The problem is thinking that all of these things are different domains when they really aren't. The web browser is just a program; its job is to fetch resources and render HTML. If you know how HTTP and HTML/CSS work, you can absolutely make great web applications.
But this requires knowledge and expertise, and also maybe not shoehorning an entire application framework into what was designed to be a collection of hyperlinked documents. I suspect this has more to do with money than anything else... the web is dead, long live the web.
That said htmx is the only remotely intriguing development I've seen in frontend dev in a decade.
But also as someone who does fullstack in a pretty much even 50/50 split, this is such a tired meme by this point seemingly from people who just refuse to actually sit down and think about the FE ecosystem for longer than 3 seconds and end up parroting this same talking point.
You could make a similarly dramatic post about the backend world. There you're even fighting which programming language you want to pick. PHP, Ruby, Go, Elixir/Erlang, C#? What about the recent mess with ElasticSearch and Redis? Where and how do you host your backend? Which DB do you use and why? Mongo, anyone?
At this point in the FE framework world, you've got 3 very stable players that have been there for a decade. Angular, React and Vue. And sure, they've each gone through some sort of reworks in the past, but nobody's forcing you to pin your dependencies `@latest`, you can pretty much always keep trucking along with whatever version you were on. We've got a huge app still running along on Vue 2 (not even 2.7 which backports the very nice Composition API) and we see no reason to bump versions to 3. I've even had some nightmare scenarios trying to update Rails and Laravel in the past that dwarf any problems I ever encountered in the frontend world.
Also, vanilla JS, HTML and CSS still exist and work just fine if you're building some small toy thing, but you'll quickly realize why these frameworks exist in the first place (or you'll do the dumb thing of building your own as some do) if you're doing anything more complex than a brochure website.
And the tooling has only gotten simpler if anything with Vite. Want to start a new frontend project? It's literally just `npm create vite@latest`, and you get a nice TUI with which you get to fully customize what you want and don't want. The README even comes with a nice little list of commands for you to run, and hosting can be done literally anywhere where you can deploy the `dist/` folder to, just like the "good" old days.
For people who always claim superiority for being the genius backenders they are, they sure seem to be having a lot of trouble with something that they will themselves say any coding monkey coming out of a bootcamp can do with relatively few problems.
There's a joke I've told many times in interviews if they ask me to define what a full-stack engineer is, to which I joke "It means I do whatever the senior engineer doesn't want to do, which 99% of the time is front-end". The people I tell it to laugh, because it's funny but also because it's true.
On the front-end you're dealing with more customer/users and it's inherently more of a servile role, while it's much easier to be stubborn, eccentric, 'powerful' in the tech-facing backend.
I'd also wager there's a certain "tech purity" angle too, given the inherent reverence foisted upon lower level languages and programming fields that is seemingly rife.
To play devil's advocate on myself, perhaps it's more that the higher end technical complexity challenges for Front-End aren't commonplace enough. I've had the fortune to work in a field where the level of necessary technical complexity on the front-end part of my job is very high, so ymmv
In the Java world alone: Spring vs EE vs Play vs Quarkas vs Micronaut vs Helidon... Tomcat vs Jetty vs Netty... Jar vs War vs Ear ... Maven vs Gradle vs Ant...
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.
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.
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.
So qualify "building apps in react" with whatever bespoke build system, router, state management, etc combination you are actually using.
Just because you found yourself a tent inside the circus doesn't mean it's not a circus.
Frontend is a mishmash of random components and packages, unless you are 100% sure in advance what are you going to use and and do chances are that you’ll run into with issues with the latest version of package X not working with build system Y due to cryptic incomprehensible reasons unless you make sure to stick with the latest “mainstream” trends (which seem to change ever 1-2 years).
You could say the same about developing in Clojure, or Rust or Golang, but somehow you typically only see this same tired rhetoric applied to JavaScript.
The rhetoric applied to JS is fully valid and justified.
Things also change in all language ecosystems. Does anyone use lein these days? Not really.
React router for routing, since.. as long as I can remember.
This notion that the ground is constantly shifting beneath you just hasn't been true for over a decade.
Use CRA + webpack, now use Vite instead, you know what? Screw CRA you should just immediately jump to Next.js instead (which seemed like a huge overkill initially, but actually seems kind of nice).
Unless you’re working on a single project or continuously following what’s new it just seems confusing and overwhelming. If I got comfortable with CRA and came back after a year or two should I still use it for a new project even if it’s bo longer the default? Will new packages/etc. still work with it? Maybe… who knows. I just know that I now have to waste time figuring that out.
When React "is just a library" but the installation instructions tell you to install some large, VC-backed framework immediately - it just doesn't sit right with me.
[0]. https://sokra.github.io/interop-test/by-tool
Just don't chase fads. Stick to things that you know are working fine.
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
However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0].
Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set.
It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX.
[0] https://htmx.org/examples/
If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API).
No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
For example a like counter wouldn’t be much good if nobody else can see your like.
You're artificially making your FCP also be your TTI, which means page navigation, when everything should be cached and fast, feels slow. That's not something e.g. Lighthouse tells you.
I recommend showing the page right away, even if there's going to be jank. Jank/Cumulative layout shifts can be fixed later.
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.
> 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
If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.
if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI
Isn't this exactly what HTMX was replacing? The client needing to have a ton of logic and state?
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.
https://htmx.org/essays/a-real-world-react-to-htmx-port/
The examples don’t even make sense, it just sounds like someone trying to use htmx like it’s react and then getting upset cos it doesn’t work how he expect it to. Lack of experience.
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.
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
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.
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:
https://htmx.org/examples/move-before/
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.
From my very personal and pragmatic point of view (I am a lone developer : I need to create software solutions that are robust and that simply work without the need to spend months to learn a new technology, that probably will be replaced by a new one in two months or so, that no customer is willing to pay), HTMX is the most pragmatic and useful solution.
It is complete in features and you can do literally anything with it and is easy to integrate in existing web applications.
I used it with CodeIgniter and now with Golang.
You could you query string as mentioned in the article, but that's not really convenient when done in a custom way for every single case.
Having said that I think that a way to go could be a community effort to settle on the ways to handle different ui patterns and interactions with some bigger project to serve as a testing ground. And that includes backend part too, we can look at what rails does with turbo
My opinion is that htmx (and similar) approach is different enough to potentially require a different set of ui interactions and it usually hurts when one tries to apply react friendly interactions to it.
Everything turns into spaghetti code really quickly.
Separation of API and frontend isn’t just for fun. It’s for making testing bearable.
Finally, mixing data modelling (database) with presentation (html output) in one place (htmx handler) goes out hand really quick too, making testing much harder.
But real coding cowboys from the golden age don’t write tests, right? :-)
I can only guess that you're trying to put all your logic and structure on the front-end, with the backend only serving what the front-end needs ad-hoc? Don't do that. Build a classic MVC app (Django, Rails, ASP.NET MVC), factor your views into small, reusable components, and use HTMX to replace page elements at that level.
Similar concept and functionality. jQuery plugin attach events like "x-post" and other attributes, sends data to server which always returns HTML.
800+ CRUD pages full of business logic, around 2k routes, single PHP server, single MySQL server, serves up to 3k requests per second seasonally, P95 around 50ms.
Team still adding and changing features every 2 weeks, even after years in production. Stack is custom PHP framework, MySQL, custom jQuery plugin that acts similar to htmx.
Onboarding is dead easy. It was made with a no-build frontend stack. Meaning there's no build pipeline to understand and fight against.
I look at React/SPA misuses and self inflicted pain, and feel sorry for them.
Handling events by writing functions that need to match unchecked strings feels _super_ clumsy to me.
I know elixir processes are very very cheap, but I still don't like the idea of maintaining a stateful connection for each live view page, especially with the lack of typing.
Jumping between my markup and the 10s of different handlers in my live view is annoying too. I like the locality of behavior principal a lot.
Again, I really like elixir, but untyped languages kind of suck for dealing with the string based world of web frontends. That's why so many javascript shops take on the complexity of typescript.
> The server sends a JSON blob that React converts into virtual DOM components.
I don't understand what is left of HTMX if you do this.
Isn't that just React?
No use if you want react though...
I’m building a thing with HTMX and hyperscript. Very excited to run into these issues for myself.
The author should try inertia.js, it has server-side routing and react templates.
I don’t know, maybe it really solves their problem, but it just feels so… wrong. I don’t know. (Shakes head, gesticulates, exits the scene)
The better we can keep state out of abstractions without losing maintainability or performance, the better.
What an amazing way of handling state!
Or the part where you use data tags for something that should be done with JSON...
On the contrary, Unpoly -which shares similarities with HTMX but is probably more high level- makes it very clear on its front page:
Granted, HTMX has "high power tools for HTML" right on its front page, but it also has "reduced code base sizes by 67% when compared with react".Anyway, as always, tools ad trade-offs...