Htmx really reminds me of CICS: load the UI, do stuff, only update the narrow part of the screen that needs to be updated -- all without writing hundreds of lines of JavaScript.
I really want to make a comment like "What version of CICS were you using that it reminded you of HTMX?" but no matter how I write it, it comes out with me sounding like a jerk. So I'm making the comment and hanging a lantern on it. My experience w/ CICS was so down in the weeds I never thought much of it's high-level architecture.
I am somewhat amused that people think the latest / greatest technology is super-new. And I think you hit on that... HTMX definitely "rhymes" with some bits of old-tech. When I was at Amazon some of our devs were floundering trying to figure out how to estimate capacity requirements for some random app they were working on. So I brought in my System 370 Capacity Planning Guide from 1978 and it made a surprisingly decent high-level introduction to how to think about planning in the cloud.
I don't get the aversion to writing "hundreds of lines of Javascript". I feel like I only hear this as an argument in the web development community, which seems to be chronically allergic to writing any amount of code.
My understanding on why Rails is falling a bit out of favor is that it presumes a webserver? You can get a lot of mileage with a static asset based frontend.
I think you're right. But for projects needing a database, I can't use anything but Rails. I tried Remix/Next because I like them but it was just taking me too long. Maybe I'm at the point in my life where I can't learn as quickly as I used to or something, but I don't understand how Rails is not getting _more_ popular with HTMX (and Hotwire).
Everything else feels pretty unproductive with a relational DB. Rust with sqlx is pretty nice and you get a very typesafe system but very slow to write.
For single person projects, this makes a ton of sense. As you start wanting to divorce the iteration of one from the other, things do start to look a little different. And if you have the constraint of "no webserver," many static site strategies come into play.
Meh. Different technologies aren't inherently better or worse than other technologies. They're better or worse for a specific set of circumstances. What I hear Karthikeyan saying is they don't need features ReactJS offers.
Like for instance... Apple Integer BASIC was a GREAT technology if all you had was an Apple ][ with 16k of RAM and were writing programs that interacted with a single user via the keyboard and monitor. If you have an array of hosts serving a web app and it's persistence tier up in someone else's datacenter, Apple Integer BASIC would not be my first choice.
But HTMX with it's conflation of presentation and business logic would also not be my first choice.
> Different technologies aren't inherently better or worse than other technologies.
That's a rather wild interpretation (to put it midly).
You have compared things on subjective terms; i.e. about BASIC being better on a limited old Apple. But that's not the same as how some technologies are objectively better or worse than others.
I'd have understood if you were comparing things on the measure of engineering tradeoffs - but instead you speak in absolutes about the 'betterness' of a technology that you do not prefer, over one known to be slow and bloated (ReactJS). That seems questionable.
ReactJS is objectively bad for an Apple ][ with 16kb.
Also, there's nothing in the statement "different technologies aren't inherently better or worse than other technologies" which requires it be interpreted in isolation or to require it to be interpreted subjectively (or objectively.)
Sometimes we have to deal with the ambiguity of natural language.
Nah, the main use case for react is making html that's so shitty and convulated that you can't write an ad blocker that works for it. If that's your goal it's probably a good choice.
I'm only half joking here, as that does seem to be one of the main reasons Facebook uses it. Another factor is that they write their backend in php.
Less tongue in cheek, why do you think that HTMX mixes presentation and business logic? Are you imagining we put business logic in the templates?
I believe we are flaming PHP users because people remember the state of PHP from 2001. It was a great language for generating HTML to put around a MySQL query. And has advanced from that. But people still remember it for what it lacks: Websocket support, sub-1-secod timers, namespace management, consistent class method call semantics, etc.
> But HTMX with it's conflation of presentation and business logic would also not be my first choice.
Have you seen React??
Htmx is just html attributes... that's it. If you want to mix things in your controllers, go ahead. But in my humble experience, the only way to write React components is to mix logic with presentation.
I've started to use Htmx when I want to "sprinkle" some interactivity to the
website, nothing big. It's similar to StimulusJs, same purpose.
I would use React (actually I don't use React anymore) when I want to build a full blown dashboard that rely on data from somewhere.
We've seen React going through massive changes lately that changed its image from being a "lightweight" library you can progressivly include to your webapp or website to acting like a web framework.
The new React docs even suppressed the option to use Vite and instead pushed the idea of using Nextjs instead which is quiet telling to how the React Team wants their library to be used.
You don't, you make reusable components in your template language or framework or whatever it is you're using to generate HTML. Most have pretty good support for template re-use and hierarchy and stuff.
I used htmx with Clojure and it was easy to mimic components as functions that return hiccup. I have a default middleware that converts it to html before sending it to the client unless I explicitly say it's a json route.
Here's my summary of this article for those who are interested in this:
- Author, who is a rails backend developer, got a job where they used rails as a back-end, and react for front-end
- The author has strong backend skills, and strong html skills, but actively avoids javascript, and hates React
- Author tried to learn react for a year, but wasn't successful.
I think this quote sums it up properly:
> ReactJS takes this dirty imperfect, embarrassing JavaScript and makes it more dirty, imperfect and embarrassing. It’s a struggle for anyone who wants to write clean code to come to terms with the messiness of React.
This reads a lot more like a pity-party than a critique of any library or framework. I think during interviews, being a lot more honest about shortcomings can really help you understand if you're going to be doing the job you want to do. The author could have been really up front with "I like Rails, I like what it comes with, but I don't like javascript." Especially in today's web tech stacks, I think mentioning where you stand with javascript is pretty important. Most of the web contracts I have want some fancy javascript somewhere.
Although that focuses more on the objective legal and performance issues, if anyone can recommend something focusing more on architectural and developer ergonomics issues I'd love to see it.
The summary does a good job of demonstrating the performance issues.
But, just browsing around the web, I noticed that my experiences don't match the criticisms:
Amazon is fast, Mastodon is fast, Twitter is (still) fast although a bit flickery, HackerNews loads slower than TheVerge for some reason. JetBrains Space is fast, Jira is a disaster. Static sites like GitHub and GitLab have been testing my patience recently - I wish GitLab was an SPA. The React pages that feel slow are often just poorly designed (momondo.com) or load ten times as much data than React could be responsible for (booking.com, icloud.com).
Admittedly, I'm not in a lab. I have content blockers, a fast computer and decent internet. But personally, I don't see a significant correlation between the framework and the perceived speed. Other aspects, such as the design of loading states seem more important.
Htmx is essentially how Facebook was built before React. Everything was server rendered in PHP and you could use special HTML tags to trigger partial updates. Ajax requests would return HTML fragments that would be injected into the correct part of the page.
It worked fine for simple use xases, but it was someone brittle and began to fail as soon as you wanted more than basic interactivity.
I really struggle to understand how someone with fundamental programming knowledge and the relevant HTML/CSS skills could run into issues like this without some serious mental blocks.
The HTML and CSS are going to be the same. Any UI state or side effects you're managing with React has to be managed in your htmx endpoints, and stateful APIs have plenty of their own quirks. You're doing the same stuff!
I can certainly understand how modern JS frameworks are harder for someone without a non-framework JS background, since the frameworks are a pretty clear evolution of how JS based web applications have been built for many years. But suggesting that developers pick React to inflate head counts and calling it "the hell-stack" makes it hard for me to think the author is engaging in good faith.
...or people could just learn javascript and stop using any framework.
Honestly, intercooler.js aka htmx always seemed to be the worst of both worlds to me: You get back the heaps of redundant, uncacheable HTML fragments from the pre-SPA days, but you also take the dependence on javascript, unpredictable page behaviour and invisible page state from SPAs.
(Example: htmx now has websocket support - that is, as long as each server-to-client message is an html fragment. Have fun writing a basic websocket chat app and echoing back the entire chatlog including UI and formatting every time someone says something)
I'm not a frontend dev, but from cursory reading of htmx docs, it seems your example implying every chat message would require sending the full log to every user is a bit of a stretch - a more natural way would be to transmit only the new messages and use one of the "before" or "after" swap settings to insert them where appropriate.
Does Ruby have a nice component based framework? HTMX is awesome, but for very quick internal apps, I'd want something thats an analog of Primefaces (component based framework).
i don't view htmx as "better" than react. htmx extends HTML as a hypermedia and makes a lot of more advanced UX patterns available within it. This makes HTML a viable option for a larger set of problems than most web developers would suspect today.
However, hypermedia has fundamental limitations due to the trade-offs it makes. So there are still times when something more sophisticated, such as React, will be the better approach.
I have written an essay on when hypermedia is appropriate and when it isn't here:
But that is not every time. And in that example they still used StimulusJS for "islands of interactivity" within the application.
I recognize that a lot of htmx users really dislike React, in particular, and, frankly, I'm not a huge fan of it myself. However I would prefer a more balanced take on the situation in general, and that software developers focus on the underlying ideas (hypermedia, HATEOAS, the uniform interface) rather than the specific tools. (I will note that there are other great hypermedia oriented JS libraries out there such as unpoly, hotwire and livewire)
Finally, if you've read this far, we have recently released our book on hypermedia systems:
Thanks for your hard work. I've actually been periodically checking on the hypermedia systems book, and glad to see it's finally been released. Do you have any plan to sell the ebook on a more open platform? PDF or EPUB on leanpub/smashwords/gumroad etc? I can read it online in the meantime, but I'd be happy to purchase if it were more generally available to non-kindle readers.
48 comments
[ 2.1 ms ] story [ 115 ms ] threadI am somewhat amused that people think the latest / greatest technology is super-new. And I think you hit on that... HTMX definitely "rhymes" with some bits of old-tech. When I was at Amazon some of our devs were floundering trying to figure out how to estimate capacity requirements for some random app they were working on. So I brought in my System 370 Capacity Planning Guide from 1978 and it made a surprisingly decent high-level introduction to how to think about planning in the cloud.
My understanding on why Rails is falling a bit out of favor is that it presumes a webserver? You can get a lot of mileage with a static asset based frontend.
I suppose the same problem largely lands for "components." Especially as you get related components?
Everything else feels pretty unproductive with a relational DB. Rust with sqlx is pretty nice and you get a very typesafe system but very slow to write.
Like for instance... Apple Integer BASIC was a GREAT technology if all you had was an Apple ][ with 16k of RAM and were writing programs that interacted with a single user via the keyboard and monitor. If you have an array of hosts serving a web app and it's persistence tier up in someone else's datacenter, Apple Integer BASIC would not be my first choice.
But HTMX with it's conflation of presentation and business logic would also not be my first choice.
That's a rather wild interpretation (to put it midly).
You have compared things on subjective terms; i.e. about BASIC being better on a limited old Apple. But that's not the same as how some technologies are objectively better or worse than others.
I'd have understood if you were comparing things on the measure of engineering tradeoffs - but instead you speak in absolutes about the 'betterness' of a technology that you do not prefer, over one known to be slow and bloated (ReactJS). That seems questionable.
Also, there's nothing in the statement "different technologies aren't inherently better or worse than other technologies" which requires it be interpreted in isolation or to require it to be interpreted subjectively (or objectively.)
Sometimes we have to deal with the ambiguity of natural language.
I'm only half joking here, as that does seem to be one of the main reasons Facebook uses it. Another factor is that they write their backend in php.
Less tongue in cheek, why do you think that HTMX mixes presentation and business logic? Are you imagining we put business logic in the templates?
Hack is the language, not PHP.
But if you're looking for PHP + HTMX + components with no js ... I built a framework for it: https://framework.getswytch.com/
Have you seen React??
Htmx is just html attributes... that's it. If you want to mix things in your controllers, go ahead. But in my humble experience, the only way to write React components is to mix logic with presentation.
I've started to use Htmx when I want to "sprinkle" some interactivity to the website, nothing big. It's similar to StimulusJs, same purpose.
I would use React (actually I don't use React anymore) when I want to build a full blown dashboard that rely on data from somewhere.
We've seen React going through massive changes lately that changed its image from being a "lightweight" library you can progressivly include to your webapp or website to acting like a web framework.
The new React docs even suppressed the option to use Vite and instead pushed the idea of using Nextjs instead which is quiet telling to how the React Team wants their library to be used.
In my preferred template language, jinja2, you'd write a macro. https://jinja.palletsprojects.com/en/3.0.x/templates/#macros
- Author, who is a rails backend developer, got a job where they used rails as a back-end, and react for front-end
- The author has strong backend skills, and strong html skills, but actively avoids javascript, and hates React
- Author tried to learn react for a year, but wasn't successful.
I think this quote sums it up properly:
> ReactJS takes this dirty imperfect, embarrassing JavaScript and makes it more dirty, imperfect and embarrassing. It’s a struggle for anyone who wants to write clean code to come to terms with the messiness of React.
This reads a lot more like a pity-party than a critique of any library or framework. I think during interviews, being a lot more honest about shortcomings can really help you understand if you're going to be doing the job you want to do. The author could have been really up front with "I like Rails, I like what it comes with, but I don't like javascript." Especially in today's web tech stacks, I think mentioning where you stand with javascript is pretty important. Most of the web contracts I have want some fancy javascript somewhere.
For those looking for a more in-depth critique of react, this article looks good: https://www.zachleat.com/web/react-criticism/
Although that focuses more on the objective legal and performance issues, if anyone can recommend something focusing more on architectural and developer ergonomics issues I'd love to see it.
But, just browsing around the web, I noticed that my experiences don't match the criticisms: Amazon is fast, Mastodon is fast, Twitter is (still) fast although a bit flickery, HackerNews loads slower than TheVerge for some reason. JetBrains Space is fast, Jira is a disaster. Static sites like GitHub and GitLab have been testing my patience recently - I wish GitLab was an SPA. The React pages that feel slow are often just poorly designed (momondo.com) or load ten times as much data than React could be responsible for (booking.com, icloud.com).
Admittedly, I'm not in a lab. I have content blockers, a fast computer and decent internet. But personally, I don't see a significant correlation between the framework and the perceived speed. Other aspects, such as the design of loading states seem more important.
There are cases where a bicycle is much more appropriate.
There are cases where a truck is much more appropriate.
These technologies are more complementing than competing.
https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-a...
It worked fine for simple use xases, but it was someone brittle and began to fail as soon as you wanted more than basic interactivity.
Top notch review
The HTML and CSS are going to be the same. Any UI state or side effects you're managing with React has to be managed in your htmx endpoints, and stateful APIs have plenty of their own quirks. You're doing the same stuff!
I can certainly understand how modern JS frameworks are harder for someone without a non-framework JS background, since the frameworks are a pretty clear evolution of how JS based web applications have been built for many years. But suggesting that developers pick React to inflate head counts and calling it "the hell-stack" makes it hard for me to think the author is engaging in good faith.
Honestly, intercooler.js aka htmx always seemed to be the worst of both worlds to me: You get back the heaps of redundant, uncacheable HTML fragments from the pre-SPA days, but you also take the dependence on javascript, unpredictable page behaviour and invisible page state from SPAs.
(Example: htmx now has websocket support - that is, as long as each server-to-client message is an html fragment. Have fun writing a basic websocket chat app and echoing back the entire chatlog including UI and formatting every time someone says something)
Why would you want that?
No, you just append.
https://docs.matestack.io/about/
i don't view htmx as "better" than react. htmx extends HTML as a hypermedia and makes a lot of more advanced UX patterns available within it. This makes HTML a viable option for a larger set of problems than most web developers would suspect today.
However, hypermedia has fundamental limitations due to the trade-offs it makes. So there are still times when something more sophisticated, such as React, will be the better approach.
I have written an essay on when hypermedia is appropriate and when it isn't here:
https://htmx.org/essays/when-to-use-hypermedia/
There are times when htmx is going to be very successful when compared to react, such as here:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
But that is not every time. And in that example they still used StimulusJS for "islands of interactivity" within the application.
I recognize that a lot of htmx users really dislike React, in particular, and, frankly, I'm not a huge fan of it myself. However I would prefer a more balanced take on the situation in general, and that software developers focus on the underlying ideas (hypermedia, HATEOAS, the uniform interface) rather than the specific tools. (I will note that there are other great hypermedia oriented JS libraries out there such as unpoly, hotwire and livewire)
Finally, if you've read this far, we have recently released our book on hypermedia systems:
https://hypermedia.systems
what's the best (most open) place to offer an epub edition?
you can also go to the book-on-one-page:
https://hypermedia.systems/hypermedia-systems/
and print it as a PDF if you'd like
good ide support these days too between emacs, intellij, and vscode.