5 ms·

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for wh

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page, even if what the user clicked on is a button heavily nested. > it's impossible to implement "optimistic UI," ... hurting the user experience 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. In the case of "useless without internet connection" do we really need optimistic UI. The actual experience of htmx is incredibly fast. There is no overhead of all the SPA stuff. No virtual dom, hardly any js. It's basically the speed of the network. In my limited practice I've actually felt the need to add delays because the update happens _too fast_. I'm still evaluating htmx but not for any of the reasons you've stated. My biggest concern is ... do I want my api to talk in html?

recursivedoubts 3y ago
> do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
- jgoodhcg 3y ago
  One great thing about your docs is the anticipation to concerns.
  - CRConrad 3y ago
    “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”.
dfabulich 3y ago
> 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.
koromak 3y ago
My app would crash and burn without optimistic UI. For simple CRUD applications sure, but most products these days aren't CRUD apps anymore.
- jonomacd 3y ago
  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.

recursivedoubts 3y ago

> do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/

jgoodhcg 3y ago
One great thing about your docs is the anticipation to concerns.
- CRConrad 3y ago
  “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”.

dfabulich 3y ago

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

koromak 3y ago

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

jonomacd 3y ago
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.