> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection.

> It's basically the speed of the network.

Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy connection, a single small request can often take 10+ seconds.

The difference between optimistic UI and non-optimistic UI on mobile web is the difference between an app that takes seconds to respond, on every click, and one that responds instantly to user gestures.

I want my stuff to work on mobile web. What I don't want is for stuff to look like it worked on mobile web, because the front end is "optimistic", but it actually didn't work. I find this to be a much worse user experience than having to wait for a round trip most of the time.

In the case of bad internet connection, "optimistic UI" is the worst solution. User thinks the data he entered has persisted, but in fact it has not. Big surprise months later when he realizes his boss's birthday reminder never got saved to his calendar.

The fix is to save data to client-side storage (IndexedDB) before attempting a network connection, and retries when connectivity is restored.

Optimistic UI probably isn't necessary for a web site, but you'll certainly want it for a web app (which is what Htmx claims to be good for).

In the real world on the mobile web we actually have, TODO apps (which is what TFA is about), calendars, notes apps, etc. all work better with client-side state synchronized to the server in the background.

React has a bunch of good libraries for this, especially TanStack React Query.

Htmx doesn't.

So actually React does not address your precious Optimistic UI, you as a developer rely on an separate 3rd party library to handle it. We all know that React, a decade old by now, has a wider ecosystem. If that's your argument, then I guess every developer using emerging or niche languages, libraries and frameworks is wrong in your eyes. However, you're a guy who relies on "State of JS" to decide what to use, as opposed to thinking for yourself.

No need to make such personal attacks in a comment here.

> a single small request can often take 10+ seconds.

Hah! Good luck getting React even to start up in that environment. Meanwhile oldschool HN will still be snappy. Speaking from experience.

What happens in your optimistically updated UI when a request eventually fails 10+ seconds after the users thought it succeeded and moved on?

In my experience optimistic UI updated don't actually make much sense if you expect users to regularly see large delays. Optimistic updates are great though to avoid the jank of a loading state that pops in/out of view for a fraction of a second.

> do I want my api to talk in html

https://htmx.org/essays/splitting-your-apis/

One great thing about your docs is the anticipation to concerns.

“So if they try this, then what can go wrong? And then if they do that, what next....?”

Must be why they're called “Recursive Doubts”.

My app would crash and burn without optimistic UI. For simple CRUD applications sure, but most products these days aren't CRUD apps anymore.

You can make use of htmx-indicator to show that the request is ongoing. From my perspective you have to be careful here. If you are _too_ optimistic and imply a request has been successfully sent to the DB when it really hasn't then users are not going to like that as their requests disappear.