Ask HN: 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.
59 comments
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.
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.
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???
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???
The real issue here is the "so we did" part. Something something cargo cult lemmings.
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).
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).
> htmx is definitely not right for most use-cases,
> the solution-space that HTMX fits in is extremely narrow
Strong disagree. HTMX is extremely flexible, surprisingly powerful and fully capable of driving quite a wide range of web applications. HTMX + Alpine even moreso, while still being far less complicated than one of the big 3 frameworks.
> the solution-space that HTMX fits in is extremely narrow
Strong disagree. HTMX is extremely flexible, surprisingly powerful and fully capable of driving quite a wide range of web applications. HTMX + Alpine even moreso, while still being far less complicated than one of the big 3 frameworks.
I'm guessing you are comparing HTMX to either pure HTML/CSS or a full react-framework-with-7986-packages solution? There are many other smaller frameworks, and many of them fit other parts of the spectrum than those other two extremes.
> big 3 frameworks
React, Angular, Vue
The existence of "many other smaller frameworks" is nice because it provides additional options for developers, but does not diminish HTMX's utility or suitability to drive a web application.
React, Angular, Vue
The existence of "many other smaller frameworks" is nice because it provides additional options for developers, but does not diminish HTMX's utility or suitability to drive a web application.
It does however diminish it's pitch as the alternative to big frameworks. My point is that there are many more points of choice than a "big framework", "htmx" or "pure html/js/css".
HTMX isn't even the biggest one outside of what you called the "big 3".
HTMX isn't even the biggest one outside of what you called the "big 3".
Of course it isn't. Since when is "big" a selling point? I want something focused and functional, not big.
Big in that they are popular, not big in the filesize/LOC sense (although those three seem to be both).
Personally, I would say that if you are doing DOM updates via AJAX calls that return HTML, HTMX is just the correct way to do it. (Unless you're using some other solution already for other reasons and it also includes that functionality.)
Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).
Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).
"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.
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.
HTMX leaves that component problem to the server side templating instead and IMHO that is a far more loose and leaky abstraction.
Yours is definitely the correct historical take. Frontend frameworks really started to take off when componentization became the norm, first in early angular with directives, and later when components were immortalized with React. Web components tried to bring us back from the land of JS, but the implementation left much to be desired for those who had already taken the leap into framework land.
This is exactly why I always recommend that htmx is best used not with a traditional templating engine, but with an HTML generation library embedded directly in your favourite programming language. Eg if you use Python there is https://htpy.dev/ - and many others in other languages.
What these all do is they allow using the full power of your programming language to create component-like abstractions much like you would in React. I show an example of this with my own library: https://github.com/yawaramin/dream-html/tree/todoapp/app
What these all do is they allow using the full power of your programming language to create component-like abstractions much like you would in React. I show an example of this with my own library: https://github.com/yawaramin/dream-html/tree/todoapp/app
What makes describing your UI with components that use a html template fragment and receive a context object a leaky abstraction, as opposed to components that use JSX and receive a props object?
> describe your UI in terms of components
Yeah, that seems to fit as the cause quite well.
Yeah, that seems to fit as the cause quite well.
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.
Whatever comes next in the mainstream frontend space must look more complex than React and friends. Money is at stake.
| $250K “just” by writing html/htmx?
Generally agree, but I do want to point out that frontend devs who truly understand HTML and CSS on a deep level are worth their weight in gold.
Compare someone like Kevin Powell to your average frontend dev when it comes to markup and styling.
Generally agree, but I do want to point out that frontend devs who truly understand HTML and CSS on a deep level are worth their weight in gold.
Compare someone like Kevin Powell to your average frontend dev when it comes to markup and styling.
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.
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 miss people caring about compatibility with older browsers. People even used to care about people who disabled JavaScript. Nowadays people seem to not gaf about older browsers. They somehow want everyone to be on the bleeding edge. What happened?
> They somehow want everyone to be on the bleeding edge. What happened?
It is one order of magnitude easier to ship a software to the last version of the major browsers than supporting all older versions of them including IE with disabled javascript.
It is one order of magnitude easier to ship a software to the last version of the major browsers than supporting all older versions of them including IE with disabled javascript.
Without a doubt it’s easier. But don’t we have more tools than before? Don’t companies & organizations have more employees/developers than before? Why are we getting less with more? I feel like there were higher standards in the jquery era.
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 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.
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.
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.
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.
As with everything in engineering the definitive answer is "it depends".
If your JSON API is guided by your UI then you are gonna have a fun time keeping with the changes (been there, done that). Sure you know that to add a new field on your page you will need to add it on the API's JSON, then on the JS client code, then on your client template... Compare this to adding it on the HTML generated on the server and... done!
There is value in differentiating between Data API and Hypermedia (UI) API, you can read more about it here https://htmx.org/essays/hypermedia-apis-vs-data-apis/
And note that is not an universal truth applicable on all cases because "it depends"
If your JSON API is guided by your UI then you are gonna have a fun time keeping with the changes (been there, done that). Sure you know that to add a new field on your page you will need to add it on the API's JSON, then on the JS client code, then on your client template... Compare this to adding it on the HTML generated on the server and... done!
There is value in differentiating between Data API and Hypermedia (UI) API, you can read more about it here https://htmx.org/essays/hypermedia-apis-vs-data-apis/
And note that is not an universal truth applicable on all cases because "it depends"
when i add something to the server generated html, first of all i have to change the html template, then i have to add the field to the function/class that feeds the data into the template, and i have to add it to the database if it is not already there.
with a frontend framework i add it to the html template in the frontend, and i add it to the function/class that generates the json output. and again to the database if not already there.
as far as i can tell, that's the same amount of code that needs to be changed.
yes, there is one piece of extra code to generate json, but that is either a standard library or something you write once. either way, the json generator should not need to be changed.
with a frontend framework i add it to the html template in the frontend, and i add it to the function/class that generates the json output. and again to the database if not already there.
as far as i can tell, that's the same amount of code that needs to be changed.
yes, there is one piece of extra code to generate json, but that is either a standard library or something you write once. either way, the json generator should not need to be changed.
exactly, this is why i prefer using frontend frameworks. the backend now doesn't need any more complex UI logic, and becomes much more reusable. i have been reusing the same backend code without changes for all websites that i built in the last 10 years.
even for a single website i can create multiple frontends (like a mobile client for example) without having to change the backend, because all frontends can use the same json api.
even for a single website i can create multiple frontends (like a mobile client for example) without having to change the backend, because all frontends can use the same json api.
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.
"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.
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.
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.
Perhaps it’s less the individual techniques, more the clarity of its underlying model. The book is worth the read by the way.
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.
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?
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?
"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?"
Great point and something I am looking at myself. With libraries like Alpine that gives you powerful JS capability to sprinkle in server side code, I am trying to see if I can get away with vanilla JS for what HTMX is doing.
Great point and something I am looking at myself. With libraries like Alpine that gives you powerful JS capability to sprinkle in server side code, I am trying to see if I can get away with vanilla JS for what HTMX is doing.
[deleted]
I wrote a blog post[1] about JS frameworks and what led up to the current mess that's called front-end web development and how new developers are re-discovering "old" tech that's fun and simple.
* [1] https://primalskill.blog/a-brief-history-of-javascript-frame...
* [1] https://primalskill.blog/a-brief-history-of-javascript-frame...
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.
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.
That's exactly what the creator of htmx keeps saying every chance he gets (including here in this very thread).
Because someone put a cool name on it.
In general, I don't think it's really a recent development, but just the latest iteration of small tricks, lean libs and personal hacks which always had been around. It's just that now someone put a good name on a well fleshed out lib, made good marketing and did it at the right time when it could prosper well in the community which is now fed up with the fat frameworks and swinging back to lean solutions again.
In general, I don't think it's really a recent development, but just the latest iteration of small tricks, lean libs and personal hacks which always had been around. It's just that now someone put a good name on a well fleshed out lib, made good marketing and did it at the right time when it could prosper well in the community which is now fed up with the fat frameworks and swinging back to lean solutions again.
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.
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.
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.
Who believes it’s a recent development? I’ve never heard that opinion that I can recall. It’s stuff we’ve been doing for 20 years, conveniently bundled into a nice to use package with good documentation.
For small projects if I can avoid using react and just use htmx/tailwind I will. It’s quite pleasant to do simple tasks in.
For small projects if I can avoid using react and just use htmx/tailwind I will. It’s quite pleasant to do simple tasks in.
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.
Sometimes that's just too much, and having a nicer alternative to do some ajax calls that doesn't suck like jQuery is nice.
As many others have said, I think HTMX was around many years ago, just in different forms.
There were many jQuery plugins that did most of what HTMX did. But maybe it has risen in popularity recently because of JavaScript fatigue?
Unrelated, but my preference when working with JavaScript:
1. None
2. jQuery
3. Alpine
4. Vue
As you can see, I have JavaScript fatigue, and prefer the lighter touch frameworks.
There were many jQuery plugins that did most of what HTMX did. But maybe it has risen in popularity recently because of JavaScript fatigue?
Unrelated, but my preference when working with JavaScript:
1. None
2. jQuery
3. Alpine
4. Vue
As you can see, I have JavaScript fatigue, and prefer the lighter touch frameworks.
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.
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.
Honestly I'm just tired of churn in the React world. React router is now on what v7? Please I just want something stable where the api doesn't break every 2 years.
Are we talking about intercooler too or just after it became HTMX?
UpdatePanel anyone?
javascript fatigue