Why do you all think that Htmx is such a recent development?
As far as I can tell, all the necessary tech was there in 2005, with ajax. So I am curious why it was developed after react, despite being so much simpler in concept/aligning more with how websites used to be developed before rendering on the client became that popular.
I created the library that would become intercooler.js in 2012 and released it in 2013, based on a mashup of $.load(), pjax & angular attributes.
The world at that time was not ready to consider an alternative to the hot new ideas coming out of the big tech companies (angular from google, react from facebook).
In 2020 during covid i decided to rewrite intercooler.js w/o the jQuery dependency and rename it to htmx. The django community started picking it up because they were being largely ignored by the next.js/etc. world and they didn't have a built in alternative like rails has w/ Turbo.
In 2023 it got picked up by an ocaml twitch streamer, teej_dv, who knew some other folks in the twitch programming community. He told ThePrimeagen about it who took a look at it in July 2023 on stream and became enthusiastic about it. At the same time FireshipDev did an "htmx in 100 seconds" short on it. That lit the rocket. I was lucky that I also had just released my book https://hypermedia.systems at around the same time (it had been cancelled by a major publisher about a year beforehand.)
Another thing that happened is that Musk bought twitter, and a large number of big tech twitter accounts left. This opened up an opportunity for new tech twitter accounts to grow up, like a fire in a forest. I am pretty good at twitter and was able to take advantage of that situation.
Here's the story visually:
https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
So I spent about a decade screaming into the void about hypermedia and had largely given up on the idea making a dent, rewrote intercooler.js just to stay sane during covid and then got very, very lucky.
I think the industry got caught up in all the cool new stuff that SPAs enabled. There’s a category of web apps that you simply can’t build without putting most of the state on the client (Google Docs, Figma etc.) and that category happens to contain most exciting web-based products that have been built lately. Not using an SPA was (is?) basically an admission that your website is and always will be “boring”.
We’re starting to (re-)discover that you can build interesting, profitable products that are technically boring.
Once upon a time, we crammed HTML, CSS, and JavaScript into single PHP files—easy and straightforward. But then, someone said, "Separate presentation from logic!" So we did.
Then someone said, "Sending HTML is old news; let's send JSON on the back end and reassemble everything with JavaScript." So we did.
Then someone said, "Why don't we put everything in a single file and call them components?" So we did.
Then someone said, "Why don't we push those components from the server instead?" So we did
Wait a minute???
What you are missing is that the pitch is well-done and the audience seems to mostly ignore the web-native (or lighter alternatives than a full react framework approach).
HTMX is a wrapper around old functionality pitched to devs that learned that frontend "really, really needs" all the complexity. It's being used by people who never needed all that complexity for tasks that didn't need a whole frontend stack.
Of course it fits them better than the alternative that they have heard about being the only modern way to build apps (a massive frontend stack where the framework isn't even a framework anymore so we built another framework around it).
The thing that htmx users often miss is that you can have most of those nice things without pulling in htmx, htmx is definitely not right for most use-cases, htmx itself is quite the large JS dependency (and you still need to write JS to use it properly), it's not "just hypermedia", and on and on.
Personally I think the solution-space that HTMX fits in is extremely narrow between normal HTML/CSS/JS and "fuller" frontend apps (hopefully built on lighter stacks than the current react meta).
"put a blob of HTML somewhere on the screen, optionally replacing a given DOM node" was achievable in the jQuery era. I definitely did it in a hand-rolled PHP app where links worked as links unless you had JS, then they'd replace the #main div with the main content of that link, and I still have all my hair. A library that does it using magic attrs is an emergent pattern that took some time to break out since SPAs have sort of eaten the world of late.
Also in that era: adding onclick to elements that semantically should never have onclick and won't have correct focus behavior and won't show up in the screen reader rotor and, and, and. And now HTMX has "When a user clicks on this div" in its docs. Some things are best left in the past. That really bums me the fuck out.
I am a very anti react person but I believe that HTMX alone isn't enough. The problem that React solves (and Svelte solves much more elegantly) is not that of reactivity etc but of being able to describe your UI in terms of components and then build your application from those lego blocks.
HTMX leaves that component problem to the server side templating instead and IMHO that is a far more loose and leaky abstraction.
I think it’s not about tech, but prestige. You have senior frontend engineers working with React, SPAs, microfrontends, and more fancy stuff earning as much as senior backend engineers nowadays. Now, imagine for a second we say “senior frontend engineers, let’s start using plain html served from the backend, perhaps using some template backend language or htmx”. Suddenly, those senior frontend engineers won’t be earning that much money anymore (can you imagine hundred of thousands of developers earning $250K “just” by writing html/htmx? I can’t).
Whatever comes next in the mainstream frontend space must look more complex than React and friends. Money is at stake.
I don’t have experience with htmx, but I was there in the 2000s and before.
From what I’ve seen of htmx, we did have something in the same vein back in those days, albeit in a more adhoc manner.
For our part we built a lot of sites that were quite content heavy with a sprinkling of interactivity. Think blogs with comment sections. By the time I stopped doing that, the pattern we had settled on was loading the comments with the page (server rendered html). When someone posted a new comment (json) we returned the rendered comment as html and injected it in place. It worked well because we could share the same template fragment for a single comment and use it in the initial render loop.
As I say, don’t have experience with htmx so maybe my understanding is off.
Probably because of the significant differences in browsers back then. Code didn't "just work" in all browsers. jQuery came along and became popular because it brought consistency and allowed you to write code that worked cross-browser. Then everyone used it and everything became spaghetti. React came along and was better. Now we're able to look at it all with many years of hindsight and seek out simpler approaches, without having to fight browser inconsistencies.
I think the reason it wasn't talked about before is because React used to be better / have less unnecessary complexity than it does today. The front-end pain has grown by an order of magnitude since.
I don't think HTMX addresses the fundamental problem of organizing (HTML) code into components, and/or the full-page-render / partial split. There is code duplication to ensure that every URL can render both fully server-side and update correctly client-side when e.g. hx-push-url happens (which most well built SPAs were able to do even before SSR, albiet somewhat slowly and poorly)
edit: Another problem that most front end frameworks seems to have stopped focusing on is building actual applications, i.e. things you would approach with https://localfirstweb.dev/ tools. HTMX can't help there at all.
I think the primary reason is the overall JS Fatigue. We are now excited to go back to something much simpler than the whole ecosystem of the last decade or so.
This is why tools like Alpine and HTMX are now gaining popularity. Personally, I am excited to get away from React/Vue etc even though they have their place.
It's techniques were used all over the place back then, it was just more common to be piecemealed together from jQuery. (or in 2005, probably prototype.js) and whatever other "scripts" you could find (as this was a time before npm and github, javascript "libraries" had no formal publishing mechanism).
I haven't used htmx, but if I'm not mistaken it uses plenty of tech that is more recent than 2005. HTML5 wasn't even released yet and the JS DOM was far from a standardized thing that you could expect consistent behavior across browser vendors. I doubt htmx developed back then would look anything like it does today.
htmx has a predecessor called intercooler.js which I think dates back to 2014 (see https://news.ycombinator.com/item?id=7613619 for example).
Because it's just not that great.
If you have a client that's going to make a request to your server, why not just expose the necessary data at a json route and let the client do what it wishes with that data? It's already the simple, general solution.
With Htmlx, you expose an html route that must be synchronized with the html already sent over the wire so that it can be inlined into the existing html. This means that if the surrounding html/classes change, you may have to update a bunch of fragments because they depend on the existing html. Even if the data itself never changes.
Sending just the data is simpler and more versatile.
The concept of "components" is borne out of developers wanting to "engineer" the generation of HTML, CSS and JS. Those are the core building blocks of the web.
"Back in my day we used