The trouble with the thin client approach is that fundamentally no control is possible on the client-side. Since the connection from client to server is unreliable, this renders such pages unnecessarily fragile, considerably more fragile than traditional server-generated pages with conventional navigation by link and form. Really, I’d say that in most places where people are inclined to use the thin client approach, they’d be better served by traditional server-generated pages with no overriding of client-side routing or other such fancy scripting.

Have you experienced this type of thin client when you have half a second’s latency, or a connection that keeps dropping out, or moderately high packet loss? I don’t think I’ve actually encountered a full thin client in the wild, but from my experiences with other poorly-done (very common) network-bound web apps in such circumstances, I can report that things are considerably worse than one would expect—that half a second’s latency inexplicably leads to things taking several seconds instead of fifty milliseconds a lot of the time (though I will admit that a pure thin client is less likely to find this so); and that very brief dropout manages to lock the page up for ten or thirty seconds until it manages to (or decides to) reconnect, or just breaks your page completely so that you have to restart and lose progress.

I have worked on apps that work offline or partially-offline, but the problems of the thin client approach are so much more than that—which is why I didn’t use the word “offline” in my earlier comment. Prefetching. Caching accessed entities so that you can revisit them without talking to the server. The bfcache, once you’re talking about simple pages rather than apps. And various more things, some of which I spoke of in my other comment here.

The thin client approach is a nice idea. It can be suitable for tightly controlled deployments. It can be suitable for a very restricted set of apps. It can be a pragmatic choice sometimes. It will tend to be better than a badly-done client-side-rendered app. But I am convinced that it is not very often the best choice, taking into account both user and business considerations; and that for consumer systems, it’s rarely a good choice.

The problem is that LiveView forces synchronous operation, whereas a significant fraction of things that would require a server trip anyway could actually be done asynchronously—that is, as far as the UI is concerned, they actually don’t require a server trip; not immediately, anyway, and the UI should only care about the immediate.

When you control server interactions on the client side, you can do things like optimistic editing, where the UI assumes the action will succeed and then does it in the background, and then handles the exceptional case where something goes wrong, most likely by returning you to a form; or things like queuing actions up when there’s no internet connection, and performing them when you get a connection again.

I want to emphasise again the importance of latency. I live in Australia. Most of the web is much slower in Australia than it is in the USA, not because of bandwidth, but because of latency.

The LiveView approach is convenient, but it’s technically not a good solution for most applications. It’s excellent for things like chat systems where being bound to synchronous operation and requiring a network connection to do things isn’t an issue, but I honestly don’t think it’s the best solution (technically, again; socially it may be) for much else.

Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.