One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state.
As the complexity increases, this problem explodes.
One can use local storage (when available), but unfortunately this isn't always available, or needed.
Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare.
It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI.
Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.
I think you're simplifying too much in order to make a point. And I've no doubt your point is valid in a lot of cases.
However, this idea of a template rendered on the server and then the same template on the client is often fraught with difficulties the more interactive your application gets.
It gets more complicated when you want to 'componetize' your javascript. A couple of years ago to do that I would have brought in something like backbone.
"I know!" I thought, "I'll switch my templating to mustache, which has a parser in both ruby and javascript. Then I'll have ruby render the page with mustache using a ruby hash. Subsquent AJAX updates then pull down JSON in the same shape and I'll have Backbone use that same mustache template to render it! That way I can send the HTML down from the server pre-rendered for speed and SEO and then progressively enhance!"
All great in theory, but then I had to build awareness into my components so that they could be instantiated without a pre-existing representation built by the server or attached to a pre-rendered version made in Ruby. (You don't want to only make a component that NEEDs a real DOM to be tested do you?)
So while I agree your advice is great for forms, I've found real world cases of highly interactive applications where it reaches its limits. And the proper progressive enhancement we need is only coming now thanks to efforts like this and isomorphic react applications.
As the complexity increases, this problem explodes.
One can use local storage (when available), but unfortunately this isn't always available, or needed.
Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare.
It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI.
Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.