5 ms·

So essentially, HTMX is not suitable for complex web apps with complex state, but it may be suitable for a simple web page that is only handling simple data. Th

So essentially, HTMX is not suitable for complex web apps with complex state, but it may be suitable for a simple web page that is only handling simple data. This is also, from what I know, what the creator of HTMX explicitly endorses. The main problem it's trying to solve is not that React is bad, but that people are using React to build simple pages which is unnecessary, like taking a private jet out to the suburbs.

dphuang2 2y ago
I like the private jet analogy. I think people are naturally comparing HTMX to React, which is the source of misunderstanding in this discussion. But its not entirely wrong to make this comparison because people are also slowly learning that HTMX may potentially be able to implement 90% of the use-cases. Now whether or not HTMX is "simpler" to implement in all of those use-cases is highly dependent on many factors like I called out in the article. Hopefully by understanding people's opinions, we can all make better engineering decisions though. I think
recursivedoubts 2y ago
i don't disagree that htmx can be a bad fit for applications with complex client-side state: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ But i also think you can push htmx a lot further than many people suspect with the judicious scripting: https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ on the gripping hand, here's a guy building a crazy-ass clojure-based spreadsheet w/ htmx + scripting: https://fxtwitter.com/RustyVermeer/status/1726697531491623168 https://fxtwitter.com/RustyVermeer/status/172669753149162316... ¯\_(ツ)_/¯
sremani 2y ago
Fat Web Client are generally bad idea and most sites are better off being Thin Web Clients with Servers doing heavy lifting and lite frameworks like htmx fill in the gaps. The more appropriate analogy is, you do not need a sky-crane to build a single family home.
- digging 2y ago
  I've personally worked on "simple" sites that actually had to do a ton of state management for user analytics and lead tracking purposes. (Whether or not all that tracking was necessary is out-of-scope for this comment...) It was pretty painful in a thin client; we were using PHP and jquery when I started. Even though the sites barely had any user-directed interactivity, I was really glad to migrate to React. Essentially I was able to shift my mental model of the site from content wrapper to software, and focus on how it could accomplish tasks, with content wrapping becoming fairly automated. In our case that was useful because it aligned with our business goals, although I didn't particularly care for it. I wonder how many bloated, React-cargo-culting sites are actually not using that bloat, vs using it for user-invisible and/or user-hostile purposes. Are devs out there building personal blogs as React SPAs still?
zer00eyz 2y ago
>> but that people are using React to build simple pages which is unnecessary JS devs running around talking about sever side rendering and hydration and how that can be good for caching... They are acting like they discovered fire and it's just 20 year old web tech. (Akami anyone). React, is a prime example of Conways law, and a Facebook product for a Facebook problem. And I will tell you that if I was shoving personalized content down the wire, or a real web app react makes sense. It is a good idea. On the other hand, should I serve a blog post with react? Probably not. How about that product page for your ecom-store? React might not make sense there either. But HTMX, or jQuery or something that runs after render would be amazing for riding the cache. And this is where we get into the problem with "modern" js. There is a ton of amazing tooling, but its a lot of it is all (react and the whole stack that comes with it) or nothing (HTMX) ... I think that there is a market gap because a lot of us know that we need something in-between. There is a reason that 70 percent of sites still have jQuery see: https://archive.is/jYEZh https://archive.is/jYEZh . And even if that number is half that, it shows that the JS market still has a massive gap.
- niutech 2y ago
  This gap can be filled by 6KB Petite Vue (https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue) or one of its forks like Petite Vue Pro (https://github.com/tmcdos/petite-vue https://github.com/tmcdos/petite-vue)
mmarian 2y ago
The reason is because it's a hassle to remember all these tools/frameworks.

dphuang2 2y ago

I like the private jet analogy. I think people are naturally comparing HTMX to React, which is the source of misunderstanding in this discussion. But its not entirely wrong to make this comparison because people are also slowly learning that HTMX may potentially be able to implement 90% of the use-cases. Now whether or not HTMX is "simpler" to implement in all of those use-cases is highly dependent on many factors like I called out in the article. Hopefully by understanding people's opinions, we can all make better engineering decisions though. I think

recursivedoubts 2y ago

i don't disagree that htmx can be a bad fit for applications with complex client-side state: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ But i also think you can push htmx a lot further than many people suspect with the judicious scripting: https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ on the gripping hand, here's a guy building a crazy-ass clojure-based spreadsheet w/ htmx + scripting: https://fxtwitter.com/RustyVermeer/status/1726697531491623168 https://fxtwitter.com/RustyVermeer/status/172669753149162316... ¯\_(ツ)_/¯

sremani 2y ago

Fat Web Client are generally bad idea and most sites are better off being Thin Web Clients with Servers doing heavy lifting and lite frameworks like htmx fill in the gaps. The more appropriate analogy is, you do not need a sky-crane to build a single family home.

digging 2y ago
I've personally worked on "simple" sites that actually had to do a ton of state management for user analytics and lead tracking purposes. (Whether or not all that tracking was necessary is out-of-scope for this comment...) It was pretty painful in a thin client; we were using PHP and jquery when I started. Even though the sites barely had any user-directed interactivity, I was really glad to migrate to React. Essentially I was able to shift my mental model of the site from content wrapper to software, and focus on how it could accomplish tasks, with content wrapping becoming fairly automated. In our case that was useful because it aligned with our business goals, although I didn't particularly care for it. I wonder how many bloated, React-cargo-culting sites are actually not using that bloat, vs using it for user-invisible and/or user-hostile purposes. Are devs out there building personal blogs as React SPAs still?

zer00eyz 2y ago

>> but that people are using React to build simple pages which is unnecessary JS devs running around talking about sever side rendering and hydration and how that can be good for caching... They are acting like they discovered fire and it's just 20 year old web tech. (Akami anyone). React, is a prime example of Conways law, and a Facebook product for a Facebook problem. And I will tell you that if I was shoving personalized content down the wire, or a real web app react makes sense. It is a good idea. On the other hand, should I serve a blog post with react? Probably not. How about that product page for your ecom-store? React might not make sense there either. But HTMX, or jQuery or something that runs after render would be amazing for riding the cache. And this is where we get into the problem with "modern" js. There is a ton of amazing tooling, but its a lot of it is all (react and the whole stack that comes with it) or nothing (HTMX) ... I think that there is a market gap because a lot of us know that we need something in-between. There is a reason that 70 percent of sites still have jQuery see: https://archive.is/jYEZh https://archive.is/jYEZh . And even if that number is half that, it shows that the JS market still has a massive gap.

niutech 2y ago
This gap can be filled by 6KB Petite Vue (https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue) or one of its forks like Petite Vue Pro (https://github.com/tmcdos/petite-vue https://github.com/tmcdos/petite-vue)

mmarian 2y ago

The reason is because it's a hassle to remember all these tools/frameworks.