|
|
|
|
|
|
by rpedela
3014 days ago
|
|
|
I don't agree that server-side rendering tends to be faster. I think it largely depends on the use case. I am going to use the word "responsive" rather than "faster" since it is more descriptive of how a UI feels. If you don't need to go to the server, performing an action will be more responsive if done client-side in general. If you do have to go to the server, then you are at the mercy of the network. However the less data transferred, the better in terms of responsiveness. In many cases, asking the server for JSON rather than HTML/JS/CSS is more responsive. Render time is also a factor. If client render time is slower than network/server time, then rendering on the server is more responsive in general. |
|
|
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.