15 ms·

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

254 points by Ralfp 2mo ago

Ralfp 2mo ago
Archive link: https://archive.ph/bLu1Z https://archive.ph/bLu1Z
deleted 2mo ago
[deleted]
deleted 2mo ago
[deleted]
asdfsa32 2mo ago
Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamental problem is that it is pretending to be a declarative language while entirely imperative.
- dajonker 2mo ago
  This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ https://triptychproject.org/ Please read this and reply when you still think it's hype.
  - asdfsa32 2mo ago
    I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not. And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks. Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
    - monooso 2mo ago
      > Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management... You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
      - asdfsa32 2mo ago
        > You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.
        asdfsa32 2mo ago
        This is ignoring the React Native and Flutter prominence on App Stores as well.
        monooso 2mo ago
        > Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main SPA frameworks don't even support JSX, and another doesn't typically use it. As I said, you may have stabilised on JSX, "we" have not.
        asdfsa32 2mo ago
        I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.
  - robertoandred 2mo ago
    The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.
- xutopia 2mo ago
  Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.
  - asdfsa32 2mo ago
    How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does. If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
    - wild_egg 2mo ago
      As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense. The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
      - asdfsa32 2mo ago
        It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
        wild_egg 2mo ago
        Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes. In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
- bcrosby95 2mo ago
  For what it's worth, your last statement is why react always felt off to me.
- pelagicAustral 2mo ago
  > hot take > 70-day old account > relentless contrarianism steer clear.
- bfjvibybd6cuvu6 2mo ago
  [flagged]
- gulugawa 2mo ago
  The overwhelming majority of websites are small projects that don't need complex tools to provide interactivity.For those websites, complexity is more likely to come from planning for complexity that will never exist. Using a tool such as htmx is an effective way for them to solve current challenges while minimizing complexity.
sgt 2mo ago
Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
- asdfsa32 2mo ago
  Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
  - sgt 2mo ago
    In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can. However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
    - asdfsa32 2mo ago
      "Complex mini app" is one hell of a concept.
      - skydhash 2mo ago
        It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
        asdfsa32 2mo ago
        A text editor or music player is hardly "mini". Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
deleted 2mo ago
[deleted]
snorremd 2mo ago
I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS. With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions. The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
- epolanski 2mo ago
  > The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX. That's how interactivity has always worked. Server-side render everything + ship interactivity via js on top of it. I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application. This is a very narrow and specific problem: navigating from page to page not causing full page reloads. But the web has changed since SPAs were needed in major ways: 1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js. 2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web. In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client. There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears. But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem. They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows. What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.
prologic 2mo ago
I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.
- johsole 2mo ago
  I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc. Have you found nice workarounds for that?
  - prologic 2mo ago
    You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it). If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.
    - bbkane 2mo ago
      Any chance you could write a hello world repo of this stack and post a link here?
      - nine_k 2mo ago
        Try asking this question to an LLM. (No, seriously.) Or to a search engine: https://share.google/dTJmGU38xw0kDSJlZ https://share.google/dTJmGU38xw0kDSJlZ
      - prologic 2mo ago
        Yes! Check out https://swag.mills.io https://swag.mills.io and the examples in the repo.
mmmmbbbhb 2mo ago
[flagged]
leviyi 2mo ago
[flagged]
deleted 2mo ago
[deleted]
thrownaway561 2mo ago
This happened 3 years ago... wondering what makes it news worthy today?
- butz 2mo ago
  We need a follow up, how this change panned out, how much did performance improve?
  - zuzululu 2mo ago
    most people i know that bought into htmx went back to react after they couldn't manage the spaghettification although i wonder if LLM changes things i am interested in moving away from React but its also what LLMs know infinitely more of than HTMX
  - Ralfp 2mo ago
    I'll write a follow in a few months, once the thing is actually out. :) The improved performance wasn't the main goal, but the HTMX version feels snappier on my purposefully mid test device (Xiaomi Redmi 8 4GB RAM).
deleted 2mo ago
[deleted]
fenestella 2mo ago
[flagged]
n4pw01f 2mo ago
Replace React / Vue with HTMX 2 years ago and still going strong. Hono + WebComponents + HTMX + serverless is the backend for my apps now.
- foxygen 2mo ago
  What is the point of using HTMX if your backend is JavaScript(Hono)?
  - sjoedev 2mo ago
    Adopting something like HTMX is primarily a UX choice, and the language you use to serve it is almost irrelevant to UX. JavaScript is a nice backend language. It’s fast, has a massive ecosystem, and many people know it well.
    - foxygen 2mo ago
      I don't see how HTMX has anything to do with UX. Could you clarify what you mean?
      - sjoedev 2mo ago
        Sure. I personally think SPAs/React have better DX than HTMX. IMO, the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster. These are UX concerns: how much the user has to download (waiting) and how long before the page becomes interactive (waiting). With HTMX, you get these benefits regardless of what language you use on the server. These benefits could be reasons the parent commenter chose HTMX, and JavaScript is a perfectly good language to serve HTMX applications for the reasons I mentioned.
        foxygen 2mo ago
        > the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of React. I understand using HTMX if you are building a backend in Go/Python/..., but if you are already using Node, I see no reason not to use TanStack Start instead.
Kuyawa 2mo ago
[dead]
hazrmard 2mo ago
Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/ https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/ https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?
- scorxn 2mo ago
  That's the architecture my B2B SaaS uses, except Vue instead of React. We deploy the SPA to a CDN and it feels snappy. Some clients access the API directly via OAuth. django-allauth is the other critical piece. Works great altogether.
wackget 2mo ago
[dead]
ErroneousBosh 2mo ago
See, one of the great things about FlaskBB is that it doesn't have React.js to begin with. But Misago sure does look good.
james2doyle 2mo ago
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results. I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/ https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server. I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time. I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.
- inigyou 2mo ago
  have a look at https://segor.de/ https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
  - benbristow 2mo ago
    [dead]
- brabel 2mo ago
  You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??
skeptic_ai 2mo ago
> A lot of pages in Misago are implemented twice: as Django templates and React.js components. I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx. > there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.
- rubyfruit 2mo ago
  MISAGO MONGO DJANGO BUN WHY WILL NOT MY FORUM RUN MISAGO MONGO DJANGO BUN PERFECT CONFIGURATION MISAGO MONGO DJANGO BUN IF YOU ARE THE CHOSEN ONE MISAGO MONGO DJANGO BUN REWRITE MY APP AND MAKE IT RUN!
rubylimetea 2mo ago
As others mentioned, not great for rich interactivity. Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal. React is designed around that kind of thing. They do some funny magic under the hood to support seamless DOM reconciliation and things like prop drilling of entire components on the prop of another, and so-on. This gives them a more granular way to manipulate the DOM without total page re-rendering. Next.js SSR works because it’s designed around React. So they’re giving you all the SSR stuff you want but you still get client-side React for rich interaction design and other SPA niceties. So if someone releases an SSR-like thing like htmx it feels like something is missing. Maybe htmx needs an opinionated framework that gets more into high performance rendering and state management. Or maybe they hone in on the “basic web pages” market. Who knows, maybe those make a comeback somewhere. PDF gets replaced with standalone HTML or something, and people use HTMX, or maybe it’s used in a dev environment for HTML email design in some future where email can have events (who knows). Couple of ideas. Right now it feel incomplete or has nowhere for me to plug it in. Love the concepts though, HTML/JS should have been like that.
- christophilus 2mo ago
  I haven’t used it with htmx, but DOM morphing seems like it’s probably a good solution to this. https://v1.htmx.org/extensions/morphdom-swap/ https://v1.htmx.org/extensions/morphdom-swap/
  - rubyfruit 2mo ago
    https://github.com/patrick-steele-idem/morphdom/issues/261 https://github.com/patrick-steele-idem/morphdom/issues/261 This issue is reporting the same kind of thing - text selection is lost on re-render
- gulugawa 2mo ago
  I designed my own mini-framework Places.js that you might be interested in looking at. https://codeberg.org/createthirdplaces/places-js https://codeberg.org/createthirdplaces/places-js Places.js supports component based rendering, and state management integrated with backend data fetching. It also has faster rendering performance than React due to the use of vanilla JS web components. Places.js is also designed to dynamically render parts of a page while making sure the rest of it is statically rendered. HTMX can be used on those parts, and be used to enhance HTML generated by components through the htmx.process() method. https://htmx.org/api/#process https://htmx.org/api/#process
urvault 2mo ago
[flagged]
jackhalford 2mo ago
I used htmx but had to migrate to svelte for storybook for development, I wish htmx had that sort of tooling
gchamonlive 2mo ago
In the realm of Server-Side rendered pages and replacing bits of the DOM, I'd recommend https://pyview.rocks/ https://pyview.rocks/. Borrows from Elixir Phoenix's Liveview and works really nice and patches are light to apply.
histiq 2mo ago
[flagged]
greatsage_sh 2mo ago
[flagged]
sqemo 2mo ago
[flagged]
feiz45607 2mo ago
[flagged]
vasanthrb 2mo ago
[flagged]

254 points by Ralfp 2mo ago

Ralfp 2mo ago

Archive link: https://archive.ph/bLu1Z https://archive.ph/bLu1Z

deleted 2mo ago

[deleted]

deleted 2mo ago

[deleted]

asdfsa32 2mo ago

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamental problem is that it is pretending to be a declarative language while entirely imperative.

dajonker 2mo ago
This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ https://triptychproject.org/ Please read this and reply when you still think it's hype.
- asdfsa32 2mo ago
  I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not. And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks. Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
  - monooso 2mo ago
    > Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management... You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
    - asdfsa32 2mo ago
      > You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.
      - asdfsa32 2mo ago
        This is ignoring the React Native and Flutter prominence on App Stores as well.
      - monooso 2mo ago
        > Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main SPA frameworks don't even support JSX, and another doesn't typically use it. As I said, you may have stabilised on JSX, "we" have not.
        asdfsa32 2mo ago
        I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.
- robertoandred 2mo ago
  The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.
xutopia 2mo ago
Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.
- asdfsa32 2mo ago
  How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does. If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
  - wild_egg 2mo ago
    As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense. The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
    - asdfsa32 2mo ago
      It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
      - wild_egg 2mo ago
        Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes. In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
bcrosby95 2mo ago
For what it's worth, your last statement is why react always felt off to me.
pelagicAustral 2mo ago
> hot take > 70-day old account > relentless contrarianism steer clear.
bfjvibybd6cuvu6 2mo ago
[flagged]
gulugawa 2mo ago
The overwhelming majority of websites are small projects that don't need complex tools to provide interactivity.For those websites, complexity is more likely to come from planning for complexity that will never exist. Using a tool such as htmx is an effective way for them to solve current challenges while minimizing complexity.

sgt 2mo ago

Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.

asdfsa32 2mo ago
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
- sgt 2mo ago
  In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can. However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
  - asdfsa32 2mo ago
    "Complex mini app" is one hell of a concept.
    - skydhash 2mo ago
      It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
      - asdfsa32 2mo ago
        A text editor or music player is hardly "mini". Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.

deleted 2mo ago

[deleted]

snorremd 2mo ago

I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS. With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions. The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.

epolanski 2mo ago
> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX. That's how interactivity has always worked. Server-side render everything + ship interactivity via js on top of it. I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application. This is a very narrow and specific problem: navigating from page to page not causing full page reloads. But the web has changed since SPAs were needed in major ways: 1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js. 2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web. In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client. There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears. But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem. They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows. What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.

prologic 2mo ago

I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.

johsole 2mo ago
I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc. Have you found nice workarounds for that?
- prologic 2mo ago
  You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it). If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.
  - bbkane 2mo ago
    Any chance you could write a hello world repo of this stack and post a link here?
    - nine_k 2mo ago
      Try asking this question to an LLM. (No, seriously.) Or to a search engine: https://share.google/dTJmGU38xw0kDSJlZ https://share.google/dTJmGU38xw0kDSJlZ
    - prologic 2mo ago
      Yes! Check out https://swag.mills.io https://swag.mills.io and the examples in the repo.

mmmmbbbhb 2mo ago

[flagged]

leviyi 2mo ago

[flagged]

deleted 2mo ago

[deleted]

thrownaway561 2mo ago

This happened 3 years ago... wondering what makes it news worthy today?

butz 2mo ago
We need a follow up, how this change panned out, how much did performance improve?
- zuzululu 2mo ago
  most people i know that bought into htmx went back to react after they couldn't manage the spaghettification although i wonder if LLM changes things i am interested in moving away from React but its also what LLMs know infinitely more of than HTMX
- Ralfp 2mo ago
  I'll write a follow in a few months, once the thing is actually out. :) The improved performance wasn't the main goal, but the HTMX version feels snappier on my purposefully mid test device (Xiaomi Redmi 8 4GB RAM).

deleted 2mo ago

[deleted]

fenestella 2mo ago

[flagged]

n4pw01f 2mo ago

Replace React / Vue with HTMX 2 years ago and still going strong. Hono + WebComponents + HTMX + serverless is the backend for my apps now.

foxygen 2mo ago
What is the point of using HTMX if your backend is JavaScript(Hono)?
- sjoedev 2mo ago
  Adopting something like HTMX is primarily a UX choice, and the language you use to serve it is almost irrelevant to UX. JavaScript is a nice backend language. It’s fast, has a massive ecosystem, and many people know it well.
  - foxygen 2mo ago
    I don't see how HTMX has anything to do with UX. Could you clarify what you mean?
    - sjoedev 2mo ago
      Sure. I personally think SPAs/React have better DX than HTMX. IMO, the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster. These are UX concerns: how much the user has to download (waiting) and how long before the page becomes interactive (waiting). With HTMX, you get these benefits regardless of what language you use on the server. These benefits could be reasons the parent commenter chose HTMX, and JavaScript is a perfectly good language to serve HTMX applications for the reasons I mentioned.
      - foxygen 2mo ago
        > the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of React. I understand using HTMX if you are building a backend in Go/Python/..., but if you are already using Node, I see no reason not to use TanStack Start instead.

Kuyawa 2mo ago

[dead]

hazrmard 2mo ago

Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/ https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/ https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?

scorxn 2mo ago
That's the architecture my B2B SaaS uses, except Vue instead of React. We deploy the SPA to a CDN and it feels snappy. Some clients access the API directly via OAuth. django-allauth is the other critical piece. Works great altogether.

wackget 2mo ago

[dead]

ErroneousBosh 2mo ago

See, one of the great things about FlaskBB is that it doesn't have React.js to begin with. But Misago sure does look good.

james2doyle 2mo ago

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results. I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/ https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server. I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time. I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.

inigyou 2mo ago
have a look at https://segor.de/ https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
- benbristow 2mo ago
  [dead]
brabel 2mo ago
You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??

skeptic_ai 2mo ago

> A lot of pages in Misago are implemented twice: as Django templates and React.js components. I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx. > there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.

rubyfruit 2mo ago
MISAGO MONGO DJANGO BUN WHY WILL NOT MY FORUM RUN MISAGO MONGO DJANGO BUN PERFECT CONFIGURATION MISAGO MONGO DJANGO BUN IF YOU ARE THE CHOSEN ONE MISAGO MONGO DJANGO BUN REWRITE MY APP AND MAKE IT RUN!

rubylimetea 2mo ago

As others mentioned, not great for rich interactivity. Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal. React is designed around that kind of thing. They do some funny magic under the hood to support seamless DOM reconciliation and things like prop drilling of entire components on the prop of another, and so-on. This gives them a more granular way to manipulate the DOM without total page re-rendering. Next.js SSR works because it’s designed around React. So they’re giving you all the SSR stuff you want but you still get client-side React for rich interaction design and other SPA niceties. So if someone releases an SSR-like thing like htmx it feels like something is missing. Maybe htmx needs an opinionated framework that gets more into high performance rendering and state management. Or maybe they hone in on the “basic web pages” market. Who knows, maybe those make a comeback somewhere. PDF gets replaced with standalone HTML or something, and people use HTMX, or maybe it’s used in a dev environment for HTML email design in some future where email can have events (who knows). Couple of ideas. Right now it feel incomplete or has nowhere for me to plug it in. Love the concepts though, HTML/JS should have been like that.

christophilus 2mo ago
I haven’t used it with htmx, but DOM morphing seems like it’s probably a good solution to this. https://v1.htmx.org/extensions/morphdom-swap/ https://v1.htmx.org/extensions/morphdom-swap/
- rubyfruit 2mo ago
  https://github.com/patrick-steele-idem/morphdom/issues/261 https://github.com/patrick-steele-idem/morphdom/issues/261 This issue is reporting the same kind of thing - text selection is lost on re-render
gulugawa 2mo ago
I designed my own mini-framework Places.js that you might be interested in looking at. https://codeberg.org/createthirdplaces/places-js https://codeberg.org/createthirdplaces/places-js Places.js supports component based rendering, and state management integrated with backend data fetching. It also has faster rendering performance than React due to the use of vanilla JS web components. Places.js is also designed to dynamically render parts of a page while making sure the rest of it is statically rendered. HTMX can be used on those parts, and be used to enhance HTML generated by components through the htmx.process() method. https://htmx.org/api/#process https://htmx.org/api/#process

urvault 2mo ago

[flagged]

jackhalford 2mo ago

I used htmx but had to migrate to svelte for storybook for development, I wish htmx had that sort of tooling

gchamonlive 2mo ago

In the realm of Server-Side rendered pages and replacing bits of the DOM, I'd recommend https://pyview.rocks/ https://pyview.rocks/. Borrows from Elixir Phoenix's Liveview and works really nice and patches are light to apply.

histiq 2mo ago

[flagged]

greatsage_sh 2mo ago

[flagged]

sqemo 2mo ago

[flagged]

feiz45607 2mo ago

[flagged]

vasanthrb 2mo ago

[flagged]