I used Turbo + Stimulus with a CodeIgniter PHP backend. Later, I used an HTMX bot with CodeIgniter and GoLang. Now, I have migrated my second brain web app (Brainminder) from HTMX to Unpoly.

I really liked HTMX, and I thank the authors for this marvelous library!

I switched from Turbo to HTMX because the latter is much more flexible, and I try to avoid Node.js as much as possible, only using it to compile some JavaScript code for Stimulus.

I finally moved from HTMX to Unpoly for the following reasons:

1. Layer support: Unpoly makes it easy to create layers and modal overlays, saving a lot of time and JavaScript code. You can achieve the same functionality with HTMX, but you have to write more code.

2. JavaScript code is better organized thanks to up.compile hooks.

3. HTMX and Unpoly treat fragments slightly differently. With HTMX, you have to use an out-of-band feature to update multiple fragments together. With Unpoly, you can easily add them to the response (and declare them in the front end, of course).

In my opinion, Unpoly has a better-organized approach to everything. On the other hand, apart from the official documentation, it is difficult to find examples for some edge-case features.

I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for.

Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well.

LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.

Isn't this what html-over-the-wire/turbo/stimulus is? [1]

[1] https://hotwired.dev/

I always thought the GWT->react branch of the webdev family tree was an inbred, unecessarily cumbersome compromise bred from JavaScript and performance metrics rather than descending from the beautiful code family we used to have with Rails and Django.

The only reason react seems to look beautiful is because it's compared to custom JavaScript state management rather than the server-state paradigm that probably makes most sense for over 90% of apps.

The only real place it makes sense is when you're Google or Facebook and those 15 milliseconds actually translate to quantifiable lost user attention.

If your app is actually useful and not just an attention farm, those 15ms are almost never worth your engineering team's sanity.

But I don't want SSR, period. My backend is an HTTP API that speaks JSON. My frontend is whatever thingimajig can talk to an HTTP API in JSON. That's it. I love it this way and see no reason why I should blur the lines between frontend and backend.

I would recommend https://data-star.dev over htmx. It is more complete. But it depends on what you are building. Datastar does everything that htmx can do and much more.

Call me grumpy but 20 years ago we were making fun of smarty - a template engine made in a template engine - and now everything looks like a solution looking for a problem.

HTMX and related libs work just fine as offline apps. I've been doing it with my personal apps I make for myself for a long time.

Also, morphdom/idiomorph get you a long way even when you have highly interactive pages, especially if you have to hit the back end anyways. If you don't need to hit the back end then a front end lib is fine. But even then, the simpler pattern of hypermedia-driven applications can be better.

See https://github.com/jon49/Soccer as an example of this.

I just don't like having to send HTML and have the backend deal with what are really frontend problems. Sending JSON is great since you can serialize most reasonable data types into it and then the backend has no responsibility for how it is rendered which helps for having mobile apps use the same backend as the website. Sending HTML just seems nuts since if you change your design you would have to change the backend too.

> That's HTMX. I didn't write JavaScript to make those work. I wrote HTML attributes.

Well you didn’t write standard HTML attributes, you wrote custom attributes that are picked up by a JS framework, so potentially the worst of both worlds depending on your problem space.

Having tried HTMX a few times, the problem is firmly in creating a backend that feeds it properly. It’s a disjointed experience for anything more complicated than updating content.