Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend.

I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced" in the positive sense. It keeps you honest.)

Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start.

I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.

The only real advice I can offer is:

Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide.

Development-by-random-recommendation is usually a recipe for disaster.

For extra credit look for places in your UI where you need to work with as much data as possible from as many different places as possible. One of places that justifies heavier front end frameworks and SPAs is when you can precompute things on the client side that make it more performant.

Things like efficient updates of large tables of data in the browser that was constructed out of multiple database tables… things like order + shipping status + customer shipping address… lots of day to day business stuff is like this and while you can manage to do it with just HTML and forms with or without JavaScript … it’s very easy to fall into performance traps between big form data submissions, potentially tricky JavaScript loops to shrink the data submission and backend N+1 query updates… it gets pretty tricky sometimes.

The point is the most complicated part of your UI may not be the most visually complex part. It can be just a simple data grid or html table… it can be the intersex of your requirements around the data being handled, the workflow/interactions on the data, and the performance/usability requirements of the users (offline editing + sync on reconnect basically requires a SPA)

This is such sage advice! Pick the hard UI/UX bits and prototype to de-risk and see how it feels once it’s working. Bravo Quekid5!

As for htmx, my team and I have been very happy with a Go + Fiber backend with Go templates and some htmx and Alpinejs for the more heavily interactive parts of a moderately complex application. Not having to deal with NodeJS, React, thousands of JS packages and overly complex configurations has been a blessing. Our system is insanely fast, plays nice with browser history, and is super cache friendly.

We make “component”-like parts such as toolbars, footers, menus, data tables, etc. with Go templates (partials called by a main template) with appropriate htmx. (Edit: we use/love Bulma for CSS.) High degree of reuse, great performance, and low complexity.

This is the best advice in the entire discussion.

Everyone's definition of 'complicated UI' is different, as is the amount of reactivity you have in your app (e.g. when this data changes, what else in the UI needs to change?).

There is one caution I will give: try and predict where you will be in 2-5 years. 5 years ago I built an app with complicated screens server-rendered with a smattering of Vue to enhance them. We are now moving more and more of the screen into Vue because the reactivity has increased. It would've been better to decide to build _this section of the app_ in Vue from the start, though situational constraints (aka the budget) would have prevented us from doing so anyhow.

That is sound advice and I take it to heart. I was mainly wondering if you'd hit any roadblocks whose existence might not have been obvious from the outset?

Nothing in particular that I wouldn't have predicted (from a detailed reading of the tech). I guess one thing to always keep in mind that these are frameworks that are limited by the client<->server interaction as a critical path. If you're doing a full SPA-type-thing you have to option to do optimistic updates and that sort of thing, but IME that's advanced stuff that only major orgs should even attempt to do.

Positive experience with Phoenix LiveView here. I don't know what you mean when you say heavily interactive but I've got: via JS hooks: drag and drop and charts; and hand built with live view: data tables with filter+sort, query builder and a simple report builder. It's pretty easy to hand off to JS when the need arises.

Have you considered https://inertiajs.com? It's still SPA-ish, but keeps server-side routing and controllers. To me it sort of looks like templates rendered in the browser with almost no need to keep state and juggle xhr calls, the app component just re-renders with new props whenever something is submitted to the server.

This comment chain:

"HTMX is great."

"I'm burnt out on frontend frameworks. HTMX has been a good change to JS heavy alternatives."

"Can you give more thoughts on it for heavy interactions?"

"You might try LiveViewJS."

"Can you tell me about your experience with LiveViewJS?"

"Have you considered InertiaJS?"

I have no intent here other than I found this circular chain amusing. Let it go on long enough and someone will without a doubt recommend HTMX as if it's something they don't expect the parent has heard of.

Is it any wonder the OP was burnt out on web dev?

https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV.

https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx.

If you hate SPAs and are chafing against Vue for building your app, it's probably worth considering if your app absolutely needs to be a JS/frontend-heavy product, or if it would be viable using a more traditional HTML+AJAX design.

After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.

Wait till you end up on a fever swamp project involving templated HTML generation. Or even a fever swamp project involving jQuery.

I’ve built those sorts of apps for 20+ years. For me, the Rails / Flask type approach is much easier to work with.

I invite you to work on a Java Server Faces project sometime. Or anything with "Portlets".

Anything you have 20 years of experience with is going to be pretty easy for you, no surprise there.

Any sufficiently complex state is going to develop edge cases that your framework of choice is going to develop sharp edges.

The question is then: has some other developer provided a useful salve/balme to this?

SvelteKit just hit 1.0. Out of all the 'modern' meta frameworks, it's the one that feels most like just writing HTML.

I'm not sure why you're posting this on a thread about HTMX. HTMX is almost certainly more like "just writing HTML"

Svelte lets you keep HTML, JS, and CSS all together, so that's nice, but it's typical use case involves writing a fair bit of Javascript/Typescript

Highly recommend the post and video mentioned above! The SaaS application shown in the video is non-trivial and appears to be very well done using htmx. Worth a close study https://htmx.org/essays/a-real-world-react-to-htmx-port/

I default to using Vue.js imported via a script tag inside static html pages styled on bootstrap. It’s perfect for basic apps and you don’t really lose a lot on interactivity. Backend, current fav is FastAPI.

Quasar framework seems to fit UI heavy and supported wide range of UI components. I have manage to integrate Tailwind.