6 ms·

HN is not real world, just like how Reddit is not real world. I am a FE with 10 years of experience, and has tried, and tried really really hard and multiple a

HN is not real world, just like how Reddit is not real world. I am a FE with 10 years of experience, and has tried, and tried really really hard and multiple attempts to make HTMX works well. Doesn’t work. UX is much worse, code discoverability is much worse, slower to code in, everything is messier than just plain React SPA with JSON data. Terrible, terrible DX and UX. Seriously, there is a reason why despite all the rage in going back to multi page Django/Rails app, very very few people actually take it seriously. You just don’t hear the negativity because most folks just tried it, saw that it is worse, and moved on without writing a blog post.

Epskampie 2y ago
I'm a freelance webdev with 15 years of experience, and recently I've made some new projects with Symfony Stimulus & Turbo to great success. A few thoughts: I tried just htmx too, too limiting. Stimulus/Turbo combination is much better. Use the right tool for the job. Highly interactive app, like an editor? Use react or similar js framework. Mostly page/document website? A backend framework is much faster and easier to develop, and much simpler to test. Use what you know yada yada.
- fullstackchris 2y ago
  A blend of both? Drop in a React component where needed on a given page! People forget (me included) that even React can be mounted into a single DOM element. With all this framework nonsense its hard to forget at the end of the days its all just javascript.
  - deleted 2y ago
    [deleted]
  - mst 2y ago
    If you're doing something something reasonably small, using preact rather than react and then wrapping it into a web component so you can just ... put it in there ... is a really nice option to have. (it may not be the right option in any given case, but it's worth knowing it's there even so)
    - throwitaway1123 2y ago
      Preact is definitely a good choice if you're looking for something lightweight. React-dom was already relatively hefty, and seems to have gotten even larger in version 19. Upgrading the React TypeScript Vite starter template from 18 to 19 increases the bundle size from 144kB to 186kB on my machine [1][2]. They've also packaged it in a way that's hard to analyze with sites like bundlephobia.com and pkg-size.dev. [1] https://github.com/facebook/react/issues/27824 https://github.com/facebook/react/issues/27824 [2] https://github.com/facebook/react/issues/29913 https://github.com/facebook/react/issues/29913
cvdub 2y ago
What kind of stuff have you been building?
kopirgan 2y ago
If I understood correctly the author of original post is also talking from real world experience, not running university research lab.
henning 2y ago
[flagged]
- dang 2y ago
  Would you please stop breaking the site guidelines? You've been doing it repeatedly and we've asked you to stop many times. Here are another couple of recent cases: https://news.ycombinator.com/item?id=42753571 https://news.ycombinator.com/item?id=42753571 https://news.ycombinator.com/item?id=42589242 https://news.ycombinator.com/item?id=42589242 I really don't want to ban an account that's been around so long and has contributed many good things in the past, but it's also not ok to degenerate to this level. Also, it sets a terrible example for other users. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and remembering the intended spirit of the site and sticking to it, we'd be grateful. p.s. I have no idea whether the GP was right or wrong, but it doesn't matter. We need you (i.e. any commenter here) to follow the guidelines regardless of how wrong someone is or you feel they are.
nchmy 2y ago
Check out Datastar (https://data-star.dev https://data-star.dev) . It's similar to htmx, but far more powerful AND simpler.
zsoltkacsandi 2y ago
> Doesn’t work. It worked for us, one of the most visited websites in my country, migrating away from a Vue.js based “modern” frontend stack. It was a huge success in terms of productivity, developer experience, and cost.
J_Shelby_J 2y ago
Can you share an example of a large react SPA that you would consider a good UX? One that doesn't have that react, not very reactive feeling, jank?
- zelphirkalt 2y ago
  May I add to this the requirement to actually be able to use standard browser functionality like back button and open links in new tabs? This should exclude roughly 98% of React SPA websites, which ended up being shoddy-made, non accessible.
sexy_seedbox 2y ago
> HTMX works well Yes, this is a fact. HTMX / Unpoly are just lighter solutions and much easier to debug.
- lenkite 2y ago
  I am surprised that Unpoly (https://unpoly.com/ https://unpoly.com/) doesn't have the same recognition as htmx/stimulus. I blame the obtuse project name. Wish the web spec just standardized a mechanism for partial page load/render. It would become the most frequently used developer technology feature of the 22nd century.
neeleshs 2y ago
Can you say more about what didn't work with HTMX? What parts make terrible DX? I also think HTMX is meant mostly for backend developers to be more productive in frontend.
- wruza 2y ago
  My experience with it is, one there’s no decent templater for nodejs, two this web1 like architecture really makes no sense as a developer. Everything is a subpage transfer rather than a meaningful operation/update. I came from desktop ui background (delphi, vb, gtk, qt, appkit), not from web. The web is all fucked up, tbh, it’s not only htmx. But at least spas vaguely resemble how normal apps function.
  - neeleshs 2y ago
    I see. HTMX and others target the browser, which is primarily an HTML renderer. So there is nothing inherently bad about page transfers. That's what hypermedia is about. React et al try to create a different paradigm on top of this. And that makes it like building a desktop UI AND a server app To me, this is not in anyway better than building something for the browser - pages and html.
pjmlp 2y ago
The Web development projects I work on, are still mostly server side rendering for the last two decades, using Java and .NET frameworks. And when not, it is due to CMS products available as SaaS like contentful. In such cases we go for Next.js due to it providing a similar experience with server side rendering and controllers. In one thing you are right, we don't take seriously development stacks that don't offer either JIT or AOT compilation.
drdaeman 2y ago
This may depend on a type of website/webapp one is working on? I have a suspicion that sometimes HTMX may actually fit nicely (e.g., for an online survey), sometimes React-like framework is the probable way to go (e.g. a marketplace app), and sometimes it could be that neither is a good option (e.g. games).
- DanielHB 2y ago
  The main problem is that it is not really viable to start with HTMX and add react (or another frontend framework) later because you end up having two completely separate stacks that are very incompatible with each other. The worst sin a large codebase can do is being inconsistent.
  - recursivedoubts 2y ago
    Ah yes. The You Are Maybe Gonna Need It (YAMGNI) principle, a classic.
    - DanielHB 2y ago
      Unfortunately yes, because you often do need it.
      - recursivedoubts 2y ago
        suppose it depends (https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/) but i see an awful lot of apps choosing SPA frameworks to just move forms into databases
delifue 2y ago
May you share some example UI and code of how HTMX cannot work well?
ramon156 2y ago
Im a gen z and the best experiences were with Angular and React. Sure, it's not always pretty, but I'd much rather have a framework that pushes me in the right direction. If I had to use HTMX for work, then I would've guaranteed used it wrong. It's just not worth the reviews and hassle if the result is less standardized. It's also harder to find HTMX dev's when there's so much React devs (or devs willing to try React, seriously if you've worked with one CSFW then React is child's play)
- pinoy420 2y ago
  As someone who hasn’t touched fe dev since vue alpha… I chose next, then remix. Then moved to svelte before I went too deep. The application I am writing could easily be done in django or .net with some simple js - but with svelte it all ties together so easily. I guess I could accomplish similar with partial views or jinja2 templates.
- lelanthran 2y ago
  > It's just not worth the reviews and hassle if the result is less standardized. I'm pretty sure HTMX is closer to standard stuff than anything you do in Angular or React.
- thraxil 2y ago
  > If I had to use HTMX for work, then I would've guaranteed used it wrong. As someone who's been doing web dev since the 90's and is currently leading a project that's built with HTMX and having onboarded a few younger/junior "react devs", you're not wrong. What I've seen is that there's a whole generation now who just don't know how to do things in a different way than by building a SPA. The difficulty onboarding those devs is always in getting them to unlearn the patterns that React/Angular/etc. have ingrained in them. I've reviewed PRs that were a mess of complicated HTMX attributes, backend logic switching on headers, etc. and pointed out that all of it could be replaced by just, like, using a plain old HTML form submit or `<a href="..."`. I wish I were kidding. They almost always start out massively overusing HTMX out of a fear of triggering the dreaded full page reload. But in a non-SPA world, with a fast backend, full page reloads take milliseconds because there aren't MBs of JS to download and execute and a bunch of client-side state to reconstruct. > It's also harder to find HTMX dev's when there's so much React devs For someone who is familiar with basic web technology (like the 20 year old version with HTTTP/HTML and minimal JS/CSS), it only takes 15 minutes or so to learn HTMX (then maybe a few days of building where you pull up the docs occasionally to remember the names of the attributes). The idea of someone calling themselves an "HTMX dev" the same way we have "React devs" is ridiculous.
YetAnotherNick 2y ago
Also underappreciated thing is the community. For any decent/widely used framework, the architecture or other aspect is good enough for your usecase. It's unlikely that you would get significant gain due to the framework for all usecase, but having a community where every question you could possibly have is in github issues is very useful.
belter 2y ago
I am starting a new web application frontend project soon calling a backend REST api. What would you recommend in 2025? I don't have legacy requirements. React? Vue? Something else?
- DanielHB 2y ago
  Use the framework that has the libraries you need, React has a lot of ecosystem around it so it tends to have everything. You don't want to spend time integrating a plain JS calendar library into your random framework when you can just use react-calendar. So look at your requirements, check the framework for libraries and tools (like deployment, hosting, monitoring etc) available. The libraries you use are much more important than the framework. Do note that although there are plenty of react chart libraries they tend to be quite under-performant. Tying chart rendering with any frontend framework building blocks ends up with bad performance. If you are dealing with >10k data-points that update often I recommend using a plain-js chart library.
  - wruza 2y ago
    Which framework-specific libraries do you even need? It’s UI, like forms and buttons and inputs and tables. I can’t imagine e.g. choosing between GTKmm and Qt over “libraries that I need”. deployment, hosting, monitoring etc Isn’t this backend-related? Generally framework agnostic? Deployment and hosting is just publishing a Vite/etc bundle, right? What is framework-specific frontend monitoring?
    - DanielHB 2y ago
      > It’s UI, like forms and buttons and inputs and tables For the most part yes, until you have a very specific requirement like complex drag and drop interactions or a complicated UI component like a calendar view. Also don't underestimate how much work it is to make a good component library from scratch, picking a framework based on the available gui libraries is important. I would say you should pick the gui-library first and then the framework. > Isn’t this backend-related? Generally framework agnostic? Depends, sentry.io for example has a pretty good NPM package that integrates well with react giving more detailed errors. Some deployment/hosting solutions integrate better with some frameworks (although it is mostly a concern for SSR or static site generators projects).
tobyhinloopen 2y ago
I've contributed to all kinds of frontend setups; Elixir LiveView, React, Vue, Angular, HTMX and many more. I've yet to find a frontend scripting solution that works well. My current stance is to have the frontend as thin as possible, no matter how it is written. Have your domain logic on the server output Plain-Old Data structures (JSON or similar) and render them with stateless, dumb views, be it a template, Vue, React or whatever. A clear boundary between the domain logic and view is important. Rails templates that can basically access anything is a terrible idea.
- egeozcan 2y ago
  I also have a lot of experience with various setups and front-end technologies, and I couldn't agree more! Furthermore, I'd say this: if you can't simply serialize your view-model and send it to the client because something might get exposed or because it's a complex object with embedded logic, your first priority should be fixing that. Only after achieving this should you even think about changing how you handle the front-end.
- cybrox 2y ago
  I have similar kind of experience and made similar conclusions for myself. In addition to the points you have made already, I would like to add that almost every larger project needs a lot of business logic on the backend side anyways. There is no possibility to have this logic in the frontend and there never will be (for security reasons at least). So given these circumstances, we usually already have quite a few people experienced with - and very efficient in - these backend technologies. So why would I spend a lot of time re-creating all kinds of routing, models, properties, etc. in an SPA? We currently run an Ember SPA for our largest project and 1/3+ of the time spent on it is pure waste because it is simply additional work to facilitate the use of this SPA at all. In every project I've worked on, the interactive and dynamic elements actually used that are written in JS end up being a lot fewer than originally anticipated. Unless you're building a product where the majority of the functionality relies on instant, realtime updates such as maybe a streaming site with chat, etc., building, maintaining and extending an SPA is a huge overhead that offers little benefit over "dumb", static views with small, isolated interactive components.
dimitrisnl 2y ago
Agree. Self-plug; Posted about the same hype I see with liveview on Phoenix https://dnlytras.com/blog/on-liveview https://dnlytras.com/blog/on-liveview
deleted 2y ago
[deleted]
meitham 2y ago
>>> You just don’t hear the negativity because most folks just tried it, saw that it is worse, and moved on without writing a blog post. How does your approach contribute to the discussion? You created a new handle named ‘htmxsucks’ solely for the purpose of making this comment! While it’s perfectly acceptable to express negative opinions about a technology and be vocal about them, doing so anonymously in this manner undermines your credibility.
- youitham 2y ago
  I too, am someone who creates a new handle for every single comment, and I would like to point out you too lack any meaningful point aside from that personal observation. Yes, it is cowardly, and I agree with the sentiment of being forthcoming with identity when making negative statements related to your field. It's actually less isolating, despite one's fearful assumption. But that is still, regardless, a point completely unrelated to the actual "discussion" you're putting on the pedestal. So now we have two posts derailing this.
  - meitham 2y ago
    I’m genuinely impressed that you took the time to create a handle based on my name, replacing “me” with “you”! I’m upvoting you for this thoughtful gesture!
renegade-otter 2y ago
In addition, I read stuff like "it's important to validate your data on the frontend AND server. It's like we are learning all of this again now.
timabdulla 2y ago
I'm not too sure about HTMX in particular, but my Rails app's FE is just HTML and Stimulus/Turbo. I'm not sure why you think it simply "doesn't work". To me, it's a lot simpler. I use forms and links and render HTML templates. That's it. I don't need to worry about building and maintaining a JSON API just to serve the front-end. I don't need to worry about distinct sets of routes and models. There's just one repo with one build pipeline and test setup. There's no need to worry about front-end state at all, since I'm just using plain-old links and forms. I'm not claiming that there is never a use for React or its ilk, but I am genuinely finding it hard to understand how one can assert that this simple HTML-based approach is categorically worse in all circumstances. In my context, the simple approach works. If I were working on something that had a high degree of inherent complexity on the front-end -- maybe a web-based video editor or some kind of WSIWYG productivity tool -- this approach would almost surely fall apart, but that's the point of engineering: Choosing the right tool for the job at hand.
davnicwil 2y ago
The truth is in a similar vein but more general - most just pick the stack they are most productive in, whatever that may be, and move on without writing a blog post. For less frustration when reading such posts that are written, read the author as writing for themselves, reporting the pros and cons for their very particular situation, and see if there's some nuggets to be found in that context. Don't read them as telling you those same pros and cons apply to your situation -- even if they veer into implying they may :-)
renegade-otter 2y ago
I have a side project that was using Vue, not even React, and every time I went back to it, it was hours of bringing everything "up to date". Everything seemed antiquated every few months I'd go back to it. It never moved past the blank landing page. Then I moved to HTMX and I did more in 5 weeks than I did in 5 years.
- sensanaty 2y ago
  > it was hours of bringing everything "up to date" Why? We still have Vue 2.6 (not even 2.7 with compAPI) projects living and chugging along just fine. Why do you feel the need to keep everything updated to latest or whatever?
  - renegade-otter 2y ago
    Because no one wants to work on an open-source project that uses fossilized versions of libraries.
    - dwaltrip 2y ago
      Don’t let perfect be the enemy of good. They certainly can’t work on it if it doesn’t exist.
prmph 2y ago
Why can't you have multi-page, but with each page being a small SPA? For me that's the best of both world, and this architecture has served me well.
- altbdoor 2y ago
  In one of the projects I worked on years before, the pages are served by Django 2, and all the fancy interactivity is handled by AngularJS (v1) (think datepickers, galleries, multi form, etc). We would use the same controller name, and just load different JS for different pages. It was an odd stack, but it served us pretty well.
graemep 2y ago
Maybe the problem is that as an FE developer you are better at doing things in the front end? The original reason the web took off to dominate the internet was because it had a very, very simple UI.
- deleted 2y ago
  [deleted]
recursivedoubts 2y ago
name checks out get the mug: https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug EDIT: lmao, the article doesn't even mention htmx and you registered the username htmxsucks just to leave a negative comment about it?
zelphirkalt 2y ago
I think only people who follow frontend hype don't take traditional web frameworks seriously, especially some as mature as Django or Rails. It may be, that very few people these days actually know how to make a website without reaching for hyped JS frameworks. The thing is, one needs to know more than just JS. One needs to know an actual backend language and learn the framework. Many web developers these days don't have this set of skills, might not even know another language than JS, even though it is not hard to learn. Not every website needs to be a "web app". Not every website needs to be some SPA. Many are better off without being an SPA. Once you are not building an SPA, many other frameworks become very viable and proven alternatives, among them Django and Rails.

Epskampie 2y ago

I'm a freelance webdev with 15 years of experience, and recently I've made some new projects with Symfony Stimulus & Turbo to great success. A few thoughts: I tried just htmx too, too limiting. Stimulus/Turbo combination is much better. Use the right tool for the job. Highly interactive app, like an editor? Use react or similar js framework. Mostly page/document website? A backend framework is much faster and easier to develop, and much simpler to test. Use what you know yada yada.

fullstackchris 2y ago
A blend of both? Drop in a React component where needed on a given page! People forget (me included) that even React can be mounted into a single DOM element. With all this framework nonsense its hard to forget at the end of the days its all just javascript.
- deleted 2y ago
  [deleted]
- mst 2y ago
  If you're doing something something reasonably small, using preact rather than react and then wrapping it into a web component so you can just ... put it in there ... is a really nice option to have. (it may not be the right option in any given case, but it's worth knowing it's there even so)
  - throwitaway1123 2y ago
    Preact is definitely a good choice if you're looking for something lightweight. React-dom was already relatively hefty, and seems to have gotten even larger in version 19. Upgrading the React TypeScript Vite starter template from 18 to 19 increases the bundle size from 144kB to 186kB on my machine [1][2]. They've also packaged it in a way that's hard to analyze with sites like bundlephobia.com and pkg-size.dev. [1] https://github.com/facebook/react/issues/27824 https://github.com/facebook/react/issues/27824 [2] https://github.com/facebook/react/issues/29913 https://github.com/facebook/react/issues/29913

cvdub 2y ago

What kind of stuff have you been building?

kopirgan 2y ago

If I understood correctly the author of original post is also talking from real world experience, not running university research lab.

henning 2y ago

[flagged]

dang 2y ago
Would you please stop breaking the site guidelines? You've been doing it repeatedly and we've asked you to stop many times. Here are another couple of recent cases: https://news.ycombinator.com/item?id=42753571 https://news.ycombinator.com/item?id=42753571 https://news.ycombinator.com/item?id=42589242 https://news.ycombinator.com/item?id=42589242 I really don't want to ban an account that's been around so long and has contributed many good things in the past, but it's also not ok to degenerate to this level. Also, it sets a terrible example for other users. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and remembering the intended spirit of the site and sticking to it, we'd be grateful. p.s. I have no idea whether the GP was right or wrong, but it doesn't matter. We need you (i.e. any commenter here) to follow the guidelines regardless of how wrong someone is or you feel they are.

nchmy 2y ago

Check out Datastar (https://data-star.dev https://data-star.dev) . It's similar to htmx, but far more powerful AND simpler.

zsoltkacsandi 2y ago

> Doesn’t work. It worked for us, one of the most visited websites in my country, migrating away from a Vue.js based “modern” frontend stack. It was a huge success in terms of productivity, developer experience, and cost.

J_Shelby_J 2y ago

Can you share an example of a large react SPA that you would consider a good UX? One that doesn't have that react, not very reactive feeling, jank?

zelphirkalt 2y ago
May I add to this the requirement to actually be able to use standard browser functionality like back button and open links in new tabs? This should exclude roughly 98% of React SPA websites, which ended up being shoddy-made, non accessible.

sexy_seedbox 2y ago

> HTMX works well Yes, this is a fact. HTMX / Unpoly are just lighter solutions and much easier to debug.

lenkite 2y ago
I am surprised that Unpoly (https://unpoly.com/ https://unpoly.com/) doesn't have the same recognition as htmx/stimulus. I blame the obtuse project name. Wish the web spec just standardized a mechanism for partial page load/render. It would become the most frequently used developer technology feature of the 22nd century.

neeleshs 2y ago

Can you say more about what didn't work with HTMX? What parts make terrible DX? I also think HTMX is meant mostly for backend developers to be more productive in frontend.

wruza 2y ago
My experience with it is, one there’s no decent templater for nodejs, two this web1 like architecture really makes no sense as a developer. Everything is a subpage transfer rather than a meaningful operation/update. I came from desktop ui background (delphi, vb, gtk, qt, appkit), not from web. The web is all fucked up, tbh, it’s not only htmx. But at least spas vaguely resemble how normal apps function.
- neeleshs 2y ago
  I see. HTMX and others target the browser, which is primarily an HTML renderer. So there is nothing inherently bad about page transfers. That's what hypermedia is about. React et al try to create a different paradigm on top of this. And that makes it like building a desktop UI AND a server app To me, this is not in anyway better than building something for the browser - pages and html.

pjmlp 2y ago

The Web development projects I work on, are still mostly server side rendering for the last two decades, using Java and .NET frameworks. And when not, it is due to CMS products available as SaaS like contentful. In such cases we go for Next.js due to it providing a similar experience with server side rendering and controllers. In one thing you are right, we don't take seriously development stacks that don't offer either JIT or AOT compilation.

drdaeman 2y ago

This may depend on a type of website/webapp one is working on? I have a suspicion that sometimes HTMX may actually fit nicely (e.g., for an online survey), sometimes React-like framework is the probable way to go (e.g. a marketplace app), and sometimes it could be that neither is a good option (e.g. games).

DanielHB 2y ago
The main problem is that it is not really viable to start with HTMX and add react (or another frontend framework) later because you end up having two completely separate stacks that are very incompatible with each other. The worst sin a large codebase can do is being inconsistent.
- recursivedoubts 2y ago
  Ah yes. The You Are Maybe Gonna Need It (YAMGNI) principle, a classic.
  - DanielHB 2y ago
    Unfortunately yes, because you often do need it.
    - recursivedoubts 2y ago
      suppose it depends (https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/) but i see an awful lot of apps choosing SPA frameworks to just move forms into databases

delifue 2y ago

May you share some example UI and code of how HTMX cannot work well?

ramon156 2y ago

Im a gen z and the best experiences were with Angular and React. Sure, it's not always pretty, but I'd much rather have a framework that pushes me in the right direction. If I had to use HTMX for work, then I would've guaranteed used it wrong. It's just not worth the reviews and hassle if the result is less standardized. It's also harder to find HTMX dev's when there's so much React devs (or devs willing to try React, seriously if you've worked with one CSFW then React is child's play)

pinoy420 2y ago
As someone who hasn’t touched fe dev since vue alpha… I chose next, then remix. Then moved to svelte before I went too deep. The application I am writing could easily be done in django or .net with some simple js - but with svelte it all ties together so easily. I guess I could accomplish similar with partial views or jinja2 templates.
lelanthran 2y ago
> It's just not worth the reviews and hassle if the result is less standardized. I'm pretty sure HTMX is closer to standard stuff than anything you do in Angular or React.
thraxil 2y ago
> If I had to use HTMX for work, then I would've guaranteed used it wrong. As someone who's been doing web dev since the 90's and is currently leading a project that's built with HTMX and having onboarded a few younger/junior "react devs", you're not wrong. What I've seen is that there's a whole generation now who just don't know how to do things in a different way than by building a SPA. The difficulty onboarding those devs is always in getting them to unlearn the patterns that React/Angular/etc. have ingrained in them. I've reviewed PRs that were a mess of complicated HTMX attributes, backend logic switching on headers, etc. and pointed out that all of it could be replaced by just, like, using a plain old HTML form submit or `<a href="..."`. I wish I were kidding. They almost always start out massively overusing HTMX out of a fear of triggering the dreaded full page reload. But in a non-SPA world, with a fast backend, full page reloads take milliseconds because there aren't MBs of JS to download and execute and a bunch of client-side state to reconstruct. > It's also harder to find HTMX dev's when there's so much React devs For someone who is familiar with basic web technology (like the 20 year old version with HTTTP/HTML and minimal JS/CSS), it only takes 15 minutes or so to learn HTMX (then maybe a few days of building where you pull up the docs occasionally to remember the names of the attributes). The idea of someone calling themselves an "HTMX dev" the same way we have "React devs" is ridiculous.

YetAnotherNick 2y ago

Also underappreciated thing is the community. For any decent/widely used framework, the architecture or other aspect is good enough for your usecase. It's unlikely that you would get significant gain due to the framework for all usecase, but having a community where every question you could possibly have is in github issues is very useful.

belter 2y ago

I am starting a new web application frontend project soon calling a backend REST api. What would you recommend in 2025? I don't have legacy requirements. React? Vue? Something else?

DanielHB 2y ago
Use the framework that has the libraries you need, React has a lot of ecosystem around it so it tends to have everything. You don't want to spend time integrating a plain JS calendar library into your random framework when you can just use react-calendar. So look at your requirements, check the framework for libraries and tools (like deployment, hosting, monitoring etc) available. The libraries you use are much more important than the framework. Do note that although there are plenty of react chart libraries they tend to be quite under-performant. Tying chart rendering with any frontend framework building blocks ends up with bad performance. If you are dealing with >10k data-points that update often I recommend using a plain-js chart library.
- wruza 2y ago
  Which framework-specific libraries do you even need? It’s UI, like forms and buttons and inputs and tables. I can’t imagine e.g. choosing between GTKmm and Qt over “libraries that I need”. deployment, hosting, monitoring etc Isn’t this backend-related? Generally framework agnostic? Deployment and hosting is just publishing a Vite/etc bundle, right? What is framework-specific frontend monitoring?
  - DanielHB 2y ago
    > It’s UI, like forms and buttons and inputs and tables For the most part yes, until you have a very specific requirement like complex drag and drop interactions or a complicated UI component like a calendar view. Also don't underestimate how much work it is to make a good component library from scratch, picking a framework based on the available gui libraries is important. I would say you should pick the gui-library first and then the framework. > Isn’t this backend-related? Generally framework agnostic? Depends, sentry.io for example has a pretty good NPM package that integrates well with react giving more detailed errors. Some deployment/hosting solutions integrate better with some frameworks (although it is mostly a concern for SSR or static site generators projects).

tobyhinloopen 2y ago

I've contributed to all kinds of frontend setups; Elixir LiveView, React, Vue, Angular, HTMX and many more. I've yet to find a frontend scripting solution that works well. My current stance is to have the frontend as thin as possible, no matter how it is written. Have your domain logic on the server output Plain-Old Data structures (JSON or similar) and render them with stateless, dumb views, be it a template, Vue, React or whatever. A clear boundary between the domain logic and view is important. Rails templates that can basically access anything is a terrible idea.

egeozcan 2y ago
I also have a lot of experience with various setups and front-end technologies, and I couldn't agree more! Furthermore, I'd say this: if you can't simply serialize your view-model and send it to the client because something might get exposed or because it's a complex object with embedded logic, your first priority should be fixing that. Only after achieving this should you even think about changing how you handle the front-end.
cybrox 2y ago
I have similar kind of experience and made similar conclusions for myself. In addition to the points you have made already, I would like to add that almost every larger project needs a lot of business logic on the backend side anyways. There is no possibility to have this logic in the frontend and there never will be (for security reasons at least). So given these circumstances, we usually already have quite a few people experienced with - and very efficient in - these backend technologies. So why would I spend a lot of time re-creating all kinds of routing, models, properties, etc. in an SPA? We currently run an Ember SPA for our largest project and 1/3+ of the time spent on it is pure waste because it is simply additional work to facilitate the use of this SPA at all. In every project I've worked on, the interactive and dynamic elements actually used that are written in JS end up being a lot fewer than originally anticipated. Unless you're building a product where the majority of the functionality relies on instant, realtime updates such as maybe a streaming site with chat, etc., building, maintaining and extending an SPA is a huge overhead that offers little benefit over "dumb", static views with small, isolated interactive components.

dimitrisnl 2y ago

Agree. Self-plug; Posted about the same hype I see with liveview on Phoenix https://dnlytras.com/blog/on-liveview https://dnlytras.com/blog/on-liveview

deleted 2y ago

[deleted]

meitham 2y ago

>>> You just don’t hear the negativity because most folks just tried it, saw that it is worse, and moved on without writing a blog post. How does your approach contribute to the discussion? You created a new handle named ‘htmxsucks’ solely for the purpose of making this comment! While it’s perfectly acceptable to express negative opinions about a technology and be vocal about them, doing so anonymously in this manner undermines your credibility.

youitham 2y ago
I too, am someone who creates a new handle for every single comment, and I would like to point out you too lack any meaningful point aside from that personal observation. Yes, it is cowardly, and I agree with the sentiment of being forthcoming with identity when making negative statements related to your field. It's actually less isolating, despite one's fearful assumption. But that is still, regardless, a point completely unrelated to the actual "discussion" you're putting on the pedestal. So now we have two posts derailing this.
- meitham 2y ago
  I’m genuinely impressed that you took the time to create a handle based on my name, replacing “me” with “you”! I’m upvoting you for this thoughtful gesture!

renegade-otter 2y ago

In addition, I read stuff like "it's important to validate your data on the frontend AND server. It's like we are learning all of this again now.

timabdulla 2y ago

I'm not too sure about HTMX in particular, but my Rails app's FE is just HTML and Stimulus/Turbo. I'm not sure why you think it simply "doesn't work". To me, it's a lot simpler. I use forms and links and render HTML templates. That's it. I don't need to worry about building and maintaining a JSON API just to serve the front-end. I don't need to worry about distinct sets of routes and models. There's just one repo with one build pipeline and test setup. There's no need to worry about front-end state at all, since I'm just using plain-old links and forms. I'm not claiming that there is never a use for React or its ilk, but I am genuinely finding it hard to understand how one can assert that this simple HTML-based approach is categorically worse in all circumstances. In my context, the simple approach works. If I were working on something that had a high degree of inherent complexity on the front-end -- maybe a web-based video editor or some kind of WSIWYG productivity tool -- this approach would almost surely fall apart, but that's the point of engineering: Choosing the right tool for the job at hand.

davnicwil 2y ago

The truth is in a similar vein but more general - most just pick the stack they are most productive in, whatever that may be, and move on without writing a blog post. For less frustration when reading such posts that are written, read the author as writing for themselves, reporting the pros and cons for their very particular situation, and see if there's some nuggets to be found in that context. Don't read them as telling you those same pros and cons apply to your situation -- even if they veer into implying they may :-)

renegade-otter 2y ago

I have a side project that was using Vue, not even React, and every time I went back to it, it was hours of bringing everything "up to date". Everything seemed antiquated every few months I'd go back to it. It never moved past the blank landing page. Then I moved to HTMX and I did more in 5 weeks than I did in 5 years.

sensanaty 2y ago
> it was hours of bringing everything "up to date" Why? We still have Vue 2.6 (not even 2.7 with compAPI) projects living and chugging along just fine. Why do you feel the need to keep everything updated to latest or whatever?
- renegade-otter 2y ago
  Because no one wants to work on an open-source project that uses fossilized versions of libraries.
  - dwaltrip 2y ago
    Don’t let perfect be the enemy of good. They certainly can’t work on it if it doesn’t exist.

prmph 2y ago

Why can't you have multi-page, but with each page being a small SPA? For me that's the best of both world, and this architecture has served me well.

altbdoor 2y ago
In one of the projects I worked on years before, the pages are served by Django 2, and all the fancy interactivity is handled by AngularJS (v1) (think datepickers, galleries, multi form, etc). We would use the same controller name, and just load different JS for different pages. It was an odd stack, but it served us pretty well.

graemep 2y ago

Maybe the problem is that as an FE developer you are better at doing things in the front end? The original reason the web took off to dominate the internet was because it had a very, very simple UI.

deleted 2y ago
[deleted]

recursivedoubts 2y ago

name checks out get the mug: https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug EDIT: lmao, the article doesn't even mention htmx and you registered the username htmxsucks just to leave a negative comment about it?

zelphirkalt 2y ago

I think only people who follow frontend hype don't take traditional web frameworks seriously, especially some as mature as Django or Rails. It may be, that very few people these days actually know how to make a website without reaching for hyped JS frameworks. The thing is, one needs to know more than just JS. One needs to know an actual backend language and learn the framework. Many web developers these days don't have this set of skills, might not even know another language than JS, even though it is not hard to learn. Not every website needs to be a "web app". Not every website needs to be some SPA. Many are better off without being an SPA. Once you are not building an SPA, many other frameworks become very viable and proven alternatives, among them Django and Rails.