4 ms·

> 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

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

_heimdall 3y ago
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.
BeefySwain 3y ago
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.
listenallyall 3y ago
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.
- dfabulich 3y ago
  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.
  - listenallyall 3y ago
    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.
    - dbmikus 3y ago
      No need to make such personal attacks in a comment here.
mixmastamyk 3y ago
> 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.

_heimdall 3y ago

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.

BeefySwain 3y ago

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.

listenallyall 3y ago

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.

dfabulich 3y ago
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.
- listenallyall 3y ago
  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.
  - dbmikus 3y ago
    No need to make such personal attacks in a comment here.

mixmastamyk 3y ago

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