Ask HN: Why do you all think that Htmx is such a recent development?

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.

1. Idea cross-pollination time is nontrivial

2. It takes time for mindshare to become disenchanted with something that is heavily pushed

3. Average experience level needs to rise to a certain level to appreciate that fewer features that compose better is superior to many features that aren't made to be composed.

Sure, the concept is not new at all, but it is distilled to a very usable form. A similar comment can be made about TailwindCSS.

Because, at some point, people realized that React-like frameworks were getting overly complicated for many simpler usecases that only needed a small fraction of the features provided by these.

Sometimes that's just too much, and having a nicer alternative to do some ajax calls that doesn't suck like jQuery is nice.

Probably has to do with the cyclical nature of this job... every one in a while we see new iterations of products that where made redundant by New-and-shiny PLC.

While not quite the same, we have seen similar takes, for example with Webforms, where the functionality resembles what some people are doing now with Hotwire, LiveView, Blazor, StimulusReflex, et al.

htmx has a predecessor called intercooler.js which I think dates back to 2014 (see https://news.ycombinator.com/item?id=7613619 for example).

I assume multiple people invented something similar over the years. They just stayed as internal projects. Not every engineer is good at or even tries to promote their inventions. And things that become generally popular are only a fraction of what's out there.

Also, I recently tried to use htmx in my project and ended up switching to web components because I just needed more control over what happened when events arrived. htmx was definitely making it more complicated.

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.

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.

Are we talking about intercooler too or just after it became HTMX?

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.

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).

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.

"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.

Facebook used something called Primer that very similar to HTMX. It was widely used until about 2010 or 2011. It slowly replaced by JS doing ad hoc DOM manipulation as engineers strove to build more sophisticated interactions, and the React was developed as a way to manage the complexity of handling updates over time.

Perhaps it’s less the individual techniques, more the clarity of its underlying model. The book is worth the read by the way.

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.

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 <table> for layout." - Me (Oh the horrors of that)

Component driven development goes all the way back to things like Visual Basic development of apps on Windows platforms (like Windows 3.11) or the equivalent on Apple back then. We have taken a document driven technology that was HTML docs linking to other HTML docs and bastardized it into building applications with heavy UX/UI requirements that replaced the VB apps and mainframe green screens of their days. I'm not dissing it, I've spent a career building web apps with it, it just was not the intended use of HTML.

There have only been a couple of technologies in the last 25+ years that I remember where components really were a first class citizen and those were when it was not HTML/CSS and it was the browser ceding control to something else like Java Applets or Flash. I haven't paid attention to WASM but I was thinking something similar would come out of that where you could use the web as a delivery platform and ignore HTML/CSS for the most part and leave that for docs.

The pendulum is swinging back towards more server-side rendering.

UpdatePanel anyone?

Everything new is old. The essential idea has been present in many forms actually. JSF, Seam, and others used standards based XML Markers that got rendered into other bits to accomplish essentially the same thing. HTMX doesn't use an XML schema, just a loose HTML convention, which is the big difference between the technologies. DWR (Direct Web Remoting)+jQuery was another form of the same thing.

Hear me out. Htmx is just what Mootools was around 2005, before they shifted gears to try to be more like jQuery to try to chase its popularity.

Making standard forms refresh with dynamic server content was one of its core competencies, and One of the big things Htmx does.

Htmx isn't anything novel. It's all been done before.

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???

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.

This is the JS framework lifecycle. Every framework is a reaction to its predecessor.

jQuery said: Vanilla JS is too unstructured and results in messy code. So, it gave us a library of convenience methods that standardized and simplified common functions.

React and Angular said: jQuery is not powerful enough to support our complex web apps. So, it gave us the virtual dom and client side state to simplify SPA development.

Htmx is saying: React and Angular are too bloated, you don't need client state or dom manipulation most of the time. So, it's designed to be a lightweight extension of the "declarative web" with functional tags for common cases.

But i'm not so sure htmx has solid footing yet. for developers considering using htmx, they'll ask themselves: if my app is so simple that it can be made using htmx, then isn't so simple that it can be made without it?

React/nextjs fatigue. Old React is much better than htmx, current React is not.