HTMX sets up an underlying network traffic pattern:
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
Wat would prevent a HTMX frontend from scaling horizontally? Maybe the backend, if it cannot scale horizontally. Otherwise, a million pages can be served the same way as a dozen. (A million is actually not so much, one average API box could suffice.)
Where HTMX would run into trouble is complicated frontend logic, where updates of one area may trigger changes in another, etc.
Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet.
HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that has to be "rendered."
> But they're still too new and unproven for the React-embroiled companies to switch just yet.
I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes
I will say though, all three were complete disasters.
It is truly refreshing to see how simple web development can be when using htmx instead of a full spa framework.
I do full stack (angular, aspnet core, mssql) development in my daytime job. It can be... tiresome.
Past couple of years i've built a soundcloud-like app using htmx, nodejs, express, mysql. Loved every minute.
But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products?
I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
No, not like Gmail. Orders of magnitude less complex than that.
No, being JS/React "native" wasn't the problem there. Actually the opposite. The developers were not willing to think about an application with state, and when they found modelling this hard (with Redux), they decided that React (a different technology) was the problem.
I think it depends on how seriously you take the frontend. Serious in the sense of design system, component library, reusability, accessibility and how well you want to test the frontend and its components in all variants independently.
Then there is the independent work. Separation of concerns would be the keyword.
If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application.
That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring.
When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements.
On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.
It was a kiosk app running on mobile tablets. It could have been a small native app, but the team, who were all pure Pythonists, tried that and decided it was too hard. So someone said React would be easy; after all it's just gluing together components, right?
The React app was built in ~3 months but the deadlines had created technical debt. When the team had problems modelling all the state, and the Redux store became an incomprehensible mess, someone said, "The problem is React. HTMX will finally make things simple".
They spent ~9 months on their HTMX rewrite and got even less far than the React version. It had numerous bugs; the UX had various regressions; it couldn't properly interact with some custom hardware; the state was now in the DB and apparently was not looking much nicer than it was in Redux, and eventually management pulled the plug.
I didn't work on it directly so I don't know how much HTMX itself stymied the project. From my interactions with the team, I think the real problem was the attitude of the developers. They decided they "hated React" when in truth they were bad at thinking about UI, particularly UI state, and unwilling to learn.
And HTMX gave succour to the fantasy they could continue not to. In fact that's how the initiative was sold to management, a way to turn non-UI devs into UI programmers.
It's basically the exact type of framework you probably built on your third or fourth Ajax project 15 years ago - declarative, progressively enhanced, simple.
Yeah it's exactly AJAX. Except instead of writing Javascript to send requests and insert the response into the document, you use declarative HTML attributes to describe what you want to happen.
It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.
Reusable components are prerogative of the templating system, such as React, or Vue, or server side templates that the framework of your choice uses. Htmx works with already rendered HTML fragments from the back end and doesn't do templating on its own, so there's simply no room for it to "solve" reusable components
well now we got Web Components baked in. People don't want to give up React cause it is where many paying job is coming from.
It is the age old problem between better tech or better pay? What is even worse younger dev come in wanting to learn React cause it is the one that most job post is looking for. We end up negative economic to tech quality.
class Counter does Component {
has Int $.count = 0;
method increment is controller {
$!count++;
self
}
method HTML {
input :id("counter-$.id"),
:name("counter"), :value($!count)
}
}
I recently found Datastar [0], another hypermedia project. It was originally inspired by htmx, but they are fully on their own (hypermedia) course. According to the devs, who had a bunch of discussions with maintainers of htmx, the htmx project considers itself finished and no new features forthcoming. It is laudible, a project considering itself complete.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
I like using both for different things. The only real complaint I have with Datastar is that its progressive-enhancement capabilities are not as nice/simple/well-defined as htmx.
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
I think your suffering from the same thing that makes 2014 feel like 5 years ago when its over a decade ago.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
I’ve been saying for a while now that browsers need something closer to a proper UI toolkit, or at minimum “batteries included” primitives built in for ages now. It’d be a much-needed paving of a desire path that’s been so heavily trodden it’s become a canyon.
The WASM approach holds promise too and is interesting to me for opening up support for non-JS languages, but a built in UI toolkit would bring the advantage of not needing a compiler or toolchain (just like the traditional web) which can be advantageous and lowers the bar for entry.
Many web developers make applications that are expected to work on every platform, every screen size, load instantly for new users, sync user state between every device instantly, and work offline (in some cases). All this takes place in an execution environment that perfectly sandboxes it, allowing users to download and run any application without any fear of viruses. Yes, the stack is complicated, but it's a complicated problem. The fact that people are making libraries to make web development simpler... well, no platform other than the web has even attempted to achieve everything I've listed, so we don't really have a point of comparison.
we've been saying it for ages. We even got everyone under the banner and came up with all sort of fixes and said "we will use transpilers till then", and javascript was supposed to change for the better.
But then microsoft took everything and ran with it. And now people believe typescript is good because their text editor lies to them.
I loooooooove HTMX. Most of the sites I build are small in scope and requirements. Using HTMX gives me a way to add a little tiny bit of interactivity at almost no cost - same templates and HTML and shit as a MPA but magically delivered as a SPA. Plus it can gracefully degrade into a normal website, which is good for everyone.
Interesting. It seems like an easy way to get JS to interact with HTML bits on the client side (if I understand it correctly).
Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.
Phoenix LiveView also solves this. One request sends a lightweight event message over web socket, and the web server responds with only the new html (or the new content to insert into specific places in the template).
so far I got HARM (Rust), HARC (Raku) and now HAM (F#)
along with Fast HTML / htpy (Python) and GOTHH (Go)
seriously, it is very good news that HTMX has uncoupled web development from the server side language choice
now there is a blossoming of many server side stacks to fill this new opportunity
I wrote https://harcstack.org because Raku is the natural successor to perl and PHP for web development due to its facility with text processing and multi-paradigm chops
Considering most of my side projects are web based and I loathe JS and prefer MPA patterns, this is very intriguing. I admit I haven’t been keeping up with HTMX or new web frameworks.
As I mentioned in a comment above, I've seen a few commercial projects attempted. But I'm hesitant to recommend HTMX, all three of them were failures (and for technical reasons not business ones)
I can't believe they still don't have a way to parse JSON responses automatically.
If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use.
I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses/error checks the json and then sets the selector's text to the value of a json key. It could really save a lot of boilerplate code IMO.
If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.
The whole idea of HTMX is to get rid of the extra steps.
I guess I could see it for decoupling your need to control the API you're using. The case where you have an existing API, whether your own or someone else's, and just want to get a new frontend hooked up to it.
I'm toying around with HTMX for my website. It's going to be sort of a wiki but a little different; the public exports from my internal knowledgebase with some extra crap mixed in.
I have lots of notes of varying types and formats. Org-mode files are all pretty standard, but there's like 3 different Markdowns and an untold number of randomly-formatted .TXT files. I want to generate their webpages on-the-fly and not have to worry about exporting it.
One of the "crap mixed in" things I want is to integrate parts of a gitweb-like interface into the notes. I reference repos and commits regularly in my notes. Would be neat to mouse-over them and get a little popup with basic info about it.
I also like that the author refers to themselves as a Technomancer. Personally I'm an metamagical artificer. I love meeting fellow adventurers.
HTMX is a solution of a problem like the following: how to add small bits of server-based interactivity to an otherwise static HTML page?
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
HTMX sets up an underlying network traffic pattern:
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
/sarcasm/
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
Wat would prevent a HTMX frontend from scaling horizontally? Maybe the backend, if it cannot scale horizontally. Otherwise, a million pages can be served the same way as a dozen. (A million is actually not so much, one average API box could suffice.)
Where HTMX would run into trouble is complicated frontend logic, where updates of one area may trigger changes in another, etc.
Is it basically like Ajax?
Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet.
HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that has to be "rendered."
> But they're still too new and unproven for the React-embroiled companies to switch just yet.
I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes
I will say though, all three were complete disasters.
Nothing magic about htmx or hypermedia: you still need to organize your code properly, and there are tasks for which it is not suited:
https://htmx.org/essays/when-to-use-hypermedia/
However, in many case, it can be much simpler architecture than alternative approaches:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
I disagree about the magical part :)
It is truly refreshing to see how simple web development can be when using htmx instead of a full spa framework.
I do full stack (angular, aspnet core, mssql) development in my daytime job. It can be... tiresome. Past couple of years i've built a soundcloud-like app using htmx, nodejs, express, mysql. Loved every minute.
Thank you for all your effort on htmx.
Edit: spelling.
But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products?
I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
I described one of them elsewhere.
No, not like Gmail. Orders of magnitude less complex than that.
No, being JS/React "native" wasn't the problem there. Actually the opposite. The developers were not willing to think about an application with state, and when they found modelling this hard (with Redux), they decided that React (a different technology) was the problem.
I think it depends on how seriously you take the frontend. Serious in the sense of design system, component library, reusability, accessibility and how well you want to test the frontend and its components in all variants independently. Then there is the independent work. Separation of concerns would be the keyword.
If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application. That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring. When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements.
On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.
Could you elaborate? What went wrong?
I'll tell you about one of them.
It was a kiosk app running on mobile tablets. It could have been a small native app, but the team, who were all pure Pythonists, tried that and decided it was too hard. So someone said React would be easy; after all it's just gluing together components, right?
The React app was built in ~3 months but the deadlines had created technical debt. When the team had problems modelling all the state, and the Redux store became an incomprehensible mess, someone said, "The problem is React. HTMX will finally make things simple".
They spent ~9 months on their HTMX rewrite and got even less far than the React version. It had numerous bugs; the UX had various regressions; it couldn't properly interact with some custom hardware; the state was now in the DB and apparently was not looking much nicer than it was in Redux, and eventually management pulled the plug.
I didn't work on it directly so I don't know how much HTMX itself stymied the project. From my interactions with the team, I think the real problem was the attitude of the developers. They decided they "hated React" when in truth they were bad at thinking about UI, particularly UI state, and unwilling to learn.
And HTMX gave succour to the fantasy they could continue not to. In fact that's how the initiative was sold to management, a way to turn non-UI devs into UI programmers.
It's basically the exact type of framework you probably built on your third or fourth Ajax project 15 years ago - declarative, progressively enhanced, simple.
Yeah it's exactly AJAX. Except instead of writing Javascript to send requests and insert the response into the document, you use declarative HTML attributes to describe what you want to happen.
so as long as you dont expect to scale, it works? Is the connection atleast long lived?
Htmx can scale. It's very basic and Htmx isn't the only technology to use that approach.
It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.
Reusable components are prerogative of the templating system, such as React, or Vue, or server side templates that the framework of your choice uses. Htmx works with already rendered HTML fragments from the back end and doesn't do templating on its own, so there's simply no room for it to "solve" reusable components
well now we got Web Components baked in. People don't want to give up React cause it is where many paying job is coming from.
It is the age old problem between better tech or better pay? What is even worse younger dev come in wanting to learn React cause it is the one that most job post is looking for. We end up negative economic to tech quality.
You make the reuseable components in the server templating language. It is like saying PHP, Django, Go etc does not scale
https://harcstack.org does components like this https://rakujourney.wordpress.com/2025/07/06/harc-stack-comp...
server-side templating languages solved this decades ago
I recently found Datastar [0], another hypermedia project. It was originally inspired by htmx, but they are fully on their own (hypermedia) course. According to the devs, who had a bunch of discussions with maintainers of htmx, the htmx project considers itself finished and no new features forthcoming. It is laudible, a project considering itself complete.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
[0] https://data-star.dev/
[1] https://data-star.dev/essays/v1_and_beyond
I like using both for different things. The only real complaint I have with Datastar is that its progressive-enhancement capabilities are not as nice/simple/well-defined as htmx.
By the time they posted that they were deprecated and everyone is now on jQuery.
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
> I don't know if picking up a minimalistic framework you know nothing about is faster
That's the whole point of HTMX: Going back to what works: trusty old HTML attributes, but giving them intuitive interactions.
Instead of learning the microframework du jour, you just add some attributes into your HTML templates, and get your desired result.
The problem is not the server cost, the problem is maintaining the (multiple) APIs altogether.
cute stack names have gone downhill since LAMP
At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
I think your suffering from the same thing that makes 2014 feel like 5 years ago when its over a decade ago.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
I’ve been saying for a while now that browsers need something closer to a proper UI toolkit, or at minimum “batteries included” primitives built in for ages now. It’d be a much-needed paving of a desire path that’s been so heavily trodden it’s become a canyon.
The WASM approach holds promise too and is interesting to me for opening up support for non-JS languages, but a built in UI toolkit would bring the advantage of not needing a compiler or toolchain (just like the traditional web) which can be advantageous and lowers the bar for entry.
You might be interested in this: https://docs.google.com/document/u/0/d/1peUSMsvFGvqD5yKh3Gpr...
It's by the Flutter team lead talking about how with WASM we can redo the web stack by eschewing HTML, CSS, and JS entirely.
That is more or less how flutter works on the web, right?
That is correct.
"works".
name one thing using "flutter web".
Flutter is just the thing startups use until they can hire a dedicated IOS person and fork the "app" codebase.
InvoiceNinja uses it, works pretty well for them.
Many web developers make applications that are expected to work on every platform, every screen size, load instantly for new users, sync user state between every device instantly, and work offline (in some cases). All this takes place in an execution environment that perfectly sandboxes it, allowing users to download and run any application without any fear of viruses. Yes, the stack is complicated, but it's a complicated problem. The fact that people are making libraries to make web development simpler... well, no platform other than the web has even attempted to achieve everything I've listed, so we don't really have a point of comparison.
we've been saying it for ages. We even got everyone under the banner and came up with all sort of fixes and said "we will use transpilers till then", and javascript was supposed to change for the better.
But then microsoft took everything and ran with it. And now people believe typescript is good because their text editor lies to them.
I loooooooove HTMX. Most of the sites I build are small in scope and requirements. Using HTMX gives me a way to add a little tiny bit of interactivity at almost no cost - same templates and HTML and shit as a MPA but magically delivered as a SPA. Plus it can gracefully degrade into a normal website, which is good for everyone.
This seems like a good place to plug my own lightweight, compilation-free library that adds reactivity and local styles to native web components:
https://vorticode.github.io/solarite
Interesting. It seems like an easy way to get JS to interact with HTML bits on the client side (if I understand it correctly).
Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.
Phoenix LiveView also solves this. One request sends a lightweight event message over web socket, and the web server responds with only the new html (or the new content to insert into specific places in the template).
“ This feels better to the user because changes feel faster”
This is debatable. Plenty of js heavy websites feel slow and clunky.
Agreed, I'm always relieved to visit sites made the "old" way because they are fast.
If it is too much of a pain with vanilla js, just use Svelte
great to see yet another H-stack
so far I got HARM (Rust), HARC (Raku) and now HAM (F#) along with Fast HTML / htpy (Python) and GOTHH (Go)
seriously, it is very good news that HTMX has uncoupled web development from the server side language choice
now there is a blossoming of many server side stacks to fill this new opportunity
I wrote https://harcstack.org because Raku is the natural successor to perl and PHP for web development due to its facility with text processing and multi-paradigm chops
Considering most of my side projects are web based and I loathe JS and prefer MPA patterns, this is very intriguing. I admit I haven’t been keeping up with HTMX or new web frameworks.
Anyone have any examples that are noteworthy?
As I mentioned in a comment above, I've seen a few commercial projects attempted. But I'm hesitant to recommend HTMX, all three of them were failures (and for technical reasons not business ones)
Would you be willing to write an essay on why they failed? I'd be happy to host it here:
https://htmx.org/essays/#on-the-other-hand
I can't believe they still don't have a way to parse JSON responses automatically.
If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use.
I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses/error checks the json and then sets the selector's text to the value of a json key. It could really save a lot of boilerplate code IMO.
The philosophy of HTMX is not to send JSON, but HTML fragments.
They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.
Then what's the point of using HTMX?
If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.
The whole idea of HTMX is to get rid of the extra steps.
I don't always have control over the remote end or due to business reasons the format can't be changed.
And since htmx also has template plugins, being able to feed JSON values into it makes sense to me... a similar project, EHTML has this feature.
But why?
Fetching data from APIs I have no control over, or ones that serve multiple purposes and use a single response format
I guess I could see it for decoupling your need to control the API you're using. The case where you have an existing API, whether your own or someone else's, and just want to get a new frontend hooked up to it.
Just put any template rendering engine in-between.
Htmx is "bring your own backend", but you do have to have a backend, be it Haskell or Zig or Gleam, that talks to your API, and renders HTML.
htmx is hypermedia oriented, so we expect hypermedia responses from the server
we do have a json extension for handling JSON responses, but it's a step away from the hypermedia architecture:
https://github.com/mariusGundersen/htmx-json
I'm toying around with HTMX for my website. It's going to be sort of a wiki but a little different; the public exports from my internal knowledgebase with some extra crap mixed in.
I have lots of notes of varying types and formats. Org-mode files are all pretty standard, but there's like 3 different Markdowns and an untold number of randomly-formatted .TXT files. I want to generate their webpages on-the-fly and not have to worry about exporting it.
One of the "crap mixed in" things I want is to integrate parts of a gitweb-like interface into the notes. I reference repos and commits regularly in my notes. Would be neat to mouse-over them and get a little popup with basic info about it.
I also like that the author refers to themselves as a Technomancer. Personally I'm an metamagical artificer. I love meeting fellow adventurers.
HTMX seems like a solution in search of a problem.
HTMX is a solution of a problem like the following: how to add small bits of server-based interactivity to an otherwise static HTML page?
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
That should be the tagline for their next tshirt~
https://swag.htmx.org/en-usd/collections/htmx-sucks
Yep. Problems like this:
https://htmx.org/essays/a-real-world-react-to-htmx-port/