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

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.

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.

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.

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.

Replace React / Vue with HTMX 2 years ago and still going strong.

Hono + WebComponents + HTMX + serverless is the backend for my apps now.

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

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?

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

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

> 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.

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]

[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.