> a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. The word "slow" here is unclear.

> a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. The word "slow" here is unclear. Thick clients work poorly on low bandwidth connections, as the first load takes too long to download the JS bundle. JS bundles can be crazy big and may get updated regularly. A user may give up waiting. Thin clients may load faster on low bandwidth connections as they can use less javascript (including zero javascript for sites that support progressive enhancement, my favorite as a NoScript user). Both thin and thick clients can use fairly minimal data transfer for follow-up actions. An HTMX patch can be pretty small, although I agree the equivalent JSON would be smaller. If "slow" means high latency, then you're right, a thick client can let the user interact with local state and the latency is only a concern when state is being synchronized (possibly with a spinner, or in the background while the user does other things). Unreliable internet is unclear to me. If the download of the JS bundle fails, then the thick client never loads. A long download time may increase the likelihood of that happening. Once both are loaded, the thick client wins as the user can work with local state. Both need to sync state sometimes. The thin client probably needs the user to initiate retry (a poor experience) and the thick client could support retry in the background (although many don't support this).