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.
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/) 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.
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.
> Forum websites mostly deliver non-interactive content
I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.
Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.
Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.
Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.
Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).
I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..
> 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.
> the average device and connection is insanely faster than 10-15 years ago
Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
> React/Vue/etc solve a specific problem: single-page application
That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.
Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.
> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience
Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
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.
How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
It seems like the wrong tool for the job to me, but I was curious and thought about it a little:
After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?)
Alternatively, implement the entire HTMX app in JS, build the app once for the NodeJS/Deno backend and once for the front-end. After page load, the frontend could take over.
Or something like that. It's a bit convoluted as PWA solutions often are.
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.
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.
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.
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.
Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
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.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.
It works quite well, and saves me an awful lot of tedious mucking about with other stuff.
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/) and django-ninja (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?
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.
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.
> 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.
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.
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.
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.
If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.
Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.
For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load
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/ Please read this and reply when you still think it's hype.
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.
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.
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/
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/) 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.
You can always make the server-side render partials based on a request header.
https://github.com/dsego/ssr-playground/blob/main/src/server...
have a look at https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??
Want to help rather than throw tomatoes?
Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?
1 reply →
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.
> Forum websites mostly deliver non-interactive content
I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.
Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.
Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/
2 replies →
I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.
Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.
Nope, HTMX could power endless scroll features if you want them
3 replies →
Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).
I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..
1 reply →
> 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.
> the average device and connection is insanely faster than 10-15 years ago
Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
6 replies →
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
> React/Vue/etc solve a specific problem: single-page application
That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.
Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.
> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience
Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
5 replies →
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.
How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
It seems like the wrong tool for the job to me, but I was curious and thought about it a little:
After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?)
Alternatively, implement the entire HTMX app in JS, build the app once for the NodeJS/Deno backend and once for the front-end. After page load, the frontend could take over.
Or something like that. It's a bit convoluted as PWA solutions often are.
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?
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.
Big fan of bDaisy and TW ...all thats missing is jQuery and Razor .cshtml to rock my 2026 mistersoft web stack. HTMX is very cool but $...
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.
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.
Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
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.
5 replies →
Astro then.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
5 replies →
That "massive hack" is supposed to be one of the core features of React.
What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.
It works quite well, and saves me an awful lot of tedious mucking about with other stuff.
1 reply →
But it is different this time, we are going back to HTML! /s
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/) and django-ninja (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?
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.
Replace React / Vue with HTMX 2 years ago and still going strong.
Hono + WebComponents + HTMX + serverless is the backend for my apps now.
What is the point of using HTMX if your backend is JavaScript(Hono)?
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.
> 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.
This happened 3 years ago... wondering what makes it news worthy today?
We need a follow up, how this change panned out, how much did performance improve?
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
Archive link: https://archive.ph/bLu1Z
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.
[flagged]
[dead]
[flagged]
[dead]
[flagged]
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.
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.
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.
8 replies →
Why would react fail for higher traffic pages?
If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.
Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.
For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load
5 replies →
For what it's worth, your last statement is why react always felt off to me.
> hot take > 70-day old account > relentless contrarianism
steer clear.
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/ Please read this and reply when you still think it's hype.
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.
5 replies →
The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.