I Reviewed 1,000s of Opinions on HTMX | Hacker News Reader

I Reviewed 1,000s of Opinions on HTMX

konfigthis.com

28 pointsdphuang230 comments

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.

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

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/

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/

on the gripping hand, here's a guy building a crazy-ass clojure-based spreadsheet w/ htmx + scripting:

https://fxtwitter.com/RustyVermeer/status/172669753149162316...

¯\_(ツ)_/¯

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.

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?

>> 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 . And even if that number is half that, it shows that the JS market still has a massive gap.

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

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

> HTMX is a step back, not forward

Funny enough, that's always been in the pro column for me. We need a step back from the path we've gone down since react was introduced. React and similar tools absolutely solve specific problems, but we shouldn't be building nearly as many sites with those tools as we do - not everyone is building Facebook.

> Current best practices often involve a more imperative style of programming, while HTMX, on the other hand, is more declarative.

> This is a fundamentally new approach to interface design

Which "best practices" are imperative, these days? I don't build many advanced web UIs but my impression is that most professional interfaces are handled with declarative XML-style schemas. It's hard to shake the feeling that this is a reinvented wheel...

Actually, you are right. I must have had a freudian slip when I was thinking about React's conditional rendering pattern (https://react.dev/learn/conditional-rendering). But I realize this is actually declarative. I think what I was trying to convey was that React involves more in-memory state management while HTMX embed that state in the HTML itself, which can be a jarring perspective shift in frontend programming.

I'll fix this sentence so I don't confuse any future readers. Thanks for the catch!

To be fair, while jsx (assuming you mean that one) indeed look like xml, the variables that get interpolated in it come from js code. Same with the events that are triggered and their callback functions.

One could argue defining what gets updated on which event via attributes (htmx) is more declarative. On the other hand, it is not fully declarative because the server is rendering the html code with the attributes. But OP argued for more declarative, which I think it is fair.

The methodology is questionable. Experimentation would be a lot more informative. Build something with a couple different sets of technologies using the best practices for each stack (practices for a React SPA should be _very_ different from a server-rendered HTMX application). Then compare metrics like development time, code size, etc and discuss findings.

Such an experiment has happened and well-documented here: https://htmx.org/essays/a-real-world-react-to-htmx-port/.

But still, experiments only happen in one context so its hard to extrapolate how the results would predict your own situation. This is why I think parsing opinions is a great through-provoking exercise.

It depends on the purpose of the analysis. To have any place in serious decision making, the methodology itself needs to be justified. One cannot simply assume that filtering social media posts by upvotes translates to real differences in the software development lifecycle. To give an anecdotal example of challenges with the given approach, most professional developers I've met do not meaningfully track time spent on tasks. So one of the questions that could be raised is: do developers on social media even have the data or experience to make these evaluations?

The original purpose of the article is to highlight opinions from the community—not to be a scientific conclusion on what approach is better.

If somebody is seeking an answer for their own engineering problems, then the necessary due diligence is always required on their part.

Please do not take this criticism personally, but it also fails as a survey. Two issues that immediately stand out are that responses were filtered out entirely for not being the most popular and then the remainder were cherry picked based on unclear criteria. You seem to have an interest in surveys and many of the skills needed to conduct them, so it would benefit you to study the topic more scientifically. Wish you the best.

none taken—I appreciate the criticism!

I wished more people wrote articles like this.

It makes me feel some kind of strange philosophical way however... like on one hand it makes me think "well yea, anyone who looks at different reviews would come to a similar conclusion", but the difference is that other people just aren't doing that, and for whatever reason let others shape their opinion on it instead of doing research.

Similarly I've noticed other people will dismiss ideas for making money from something "because it has already been done to death." But yet someone else comes along and does just that, again, and turns a good profit, and now the critic is silent. The only difference is the critic simply didn't do the same thing themselves, but they could have.

Am I just slowly arriving at a weird "this is how intelligence works" cross-roads? I might be losing it...

Man I actually feel like there’s no meat to this article at all - no offense to the author - but no conclusion or recommendation or much of anything seems to be reached by the end. It’s kind of just summarizing some opinions without judging or critiquing or evaluating them - all of their paragraphs just seem to add up to “to be fair, both sides have an understandable point, and may be correct in certain contexts” - and then the article moves onto the next header, under which the process repeats.

Honestly I didn’t get much at all out of this, other than a fairly transparent attempt to drive traffic to their site, so readers would see them plug their own product.

Am I the only one? Is this unnecessarily harsh?

not harsh and not untrue :)

But for context, the original intention of this article is to highlight opinions from the community. I feel that interleaving my own opinions would be untrue to the original intent.

I very much appreciated your article and the unbiased comparison, please don't stop doing these :) I think my only comment on it at the moment might be to show more usage of common scenarios between e.g. htmx vs other paradigms or frameworks.

Thanks for the kind comment! Glad you enjoy the content style—it takes a lot of time to gather comments.

Hm, definitely interesting to have some inline example/resources, I can see examples augmenting the original opinions.

I think it could be viewed by some as a bit harsh. Maybe a better approach could have been to simply ask what the intended purpose was instead of guessing there was supposed to be a point you just weren't grasping?

I do appreciate summarizing the pros and cons of things from a perspective of _actually_ trying to use all of them to accomplish a common goal though.

I think they were just trying to not give a purely subjective opinion on their differences... and one could argue that this information might be useful to make one's own choice as to which solution to use for their next project.

I didn't get the sense that they were trying to plug anything or drive traffic at all. I could also argue that merely linking to a blog post in the first place might be doing the same thing... but where should the line by drawn and who should the authority be on that?

appreciate the comment! I think I understand what you mean and I get the feeling that you are crossing into the land of aristotle haha.

HTMX is not lightweight, its size is 44KB minified, whereas you can get similar behavior using 166-byte (sic!) HTMZ: https://leanrada.com/htmz/

This piece may not be AI-generated, but it sure fails to rise above the quality of AI writing.

This is what I felt about htmx as well. cool for your own personal blog, but not really meant for that next big startup.

Depends on the startup. I'd say it's probably better suited to a middle ground: the primarily server-rendered application that needs interactivity without committing to a huge build ecosystem.

For most personal blogs, even HTMX is probably overkill.

A personal blog probably only needs any library besides a markdown to HTML renderer (for the developer-focused) or framework that has a built-in WYSIWYG editor and CMS.

From memory, i'm not to sure that a lot of problems that startups solve need a "thick-client" architecture. I think the canonical "thick-client" products are google sheets and google docs-esque products. I could be wrong about the actually distribution on this though. I think the author of HTMX phrased is correctly in that it really depends on where you are providing value—the backend or frontend. That would determine the viability of adopting HTMX.

Reply on news.ycombinator.com