I found this little thread on Twitter interesting, complaining Hey (powered by hotwire) is too slow
which is a fair complaint, I would say.
> For a typically long running app like an email client, the obsession with shipping as little JavaScript as possible is actually detrimental to the end UX.
I never leave an email tab open, but even if I did, I first need it to load...
Minimal JS pages often have very little direct interaction built in, so they feel blazing fast when the connection is good and the payload is small (HN is a great example) but terribly slow if your internet connection is bad and it's not masking the network delays (again, HN is a great example).
The 2-5s mentioned on Twitter are something else though, perhaps the Hey app is being transferred through a saturated connection in the US or something.
I presume you can lie to user by pretending that their change was instantly submitted, while syncing in background. In that case, yes, SPA all the way.
Optimistic updates are great for inconsequential stuff like an HN upvote. The user likely doesn't even want to see an error message if their upvote timed out.
But it definitely is "lying to the user", or better phrased "breaking user expectations". It's just that the user isn't likely to care except for important actions.
For example, imagine applying optimistic update to sending an email. The user would expect to be able to close their laptop after sending an email and seeing the UI transition. It would be catastrophic if the email was never actually sent.
Optimistic updates are best relegated to micro-polish imo. Frankly, I think it's overused especially in combination with autosave UI.
If you're not invalidating the cached code multiple times per day (which, in fairness, a lot of the stuff from Google, Facebook, etc probably are), an SPA should use less data over time than a comparable server rendered app. The initial outlay is bigger, but once it's cached you only need the raw data as you navigate around.