I agree that client-side UI modifications tend to be faster if no server round-trip is necessary.
Rendering HTML will, however, tend to be faster than having a client parse and interpret JSON, and then manipulate the (shadow) DOM accordingly.
And then it always felt wrong to me that I have to force countless clients to do the exact same view transformations, which could have been done once, on the server, and cached.
For a new project, I'm prerendering HTML fragments via AJAX with IntercoolerJS - it's a pleasure to work with, and the developer and user get both the best experience of those two worlds: A dynamic, blazingly fast UI that feels like an SPA, but degrades gracefully even for the Emacs-w3m user and Googlebot.
I also found it's really worth it to move servers or reverse proxies closer to the client - independent of client/server rendering. Users shouldn't wait more than 200ms for an Ajax request to finish.
Rendering HTML will, however, tend to be faster than having a client parse and interpret JSON, and then manipulate the (shadow) DOM accordingly.
And then it always felt wrong to me that I have to force countless clients to do the exact same view transformations, which could have been done once, on the server, and cached.
For a new project, I'm prerendering HTML fragments via AJAX with IntercoolerJS - it's a pleasure to work with, and the developer and user get both the best experience of those two worlds: A dynamic, blazingly fast UI that feels like an SPA, but degrades gracefully even for the Emacs-w3m user and Googlebot.
I also found it's really worth it to move servers or reverse proxies closer to the client - independent of client/server rendering. Users shouldn't wait more than 200ms for an Ajax request to finish.