|
|
|
|
|
|
by mason55
3758 days ago
|
|
|
It's not a matter of being "hipstery", the drawback is that each time you refresh the view you have to resend all the markup. You're increasing the total amount of data that's going back and forth between the browser and the server. By sending the markup once and then dynamically populating it you can have much faster transitions between objects that use the same view. What you really want to do is provide progressive enhancement where the first thing a user sees is usable and then more features become available without disrupting whatever the user has started doing (e.g. don't reflow the page while they're trying to read or browse). One way to achieve this is rendering the initial view on the server side and then doing updates via AJAX request but this has meant writing your rendering code twice, once on the server side and once on the client side. This is a reason that node.js and isomorphic JavaScript in general have become so popular. |
|
|
> ...the drawback is that each time you refresh the view you have to resend all the markup. You're increasing the total amount of data that's going back and forth between the browser and the server.
For like 99.9% of applications this is a non-issue. For crying out loud, StackOverflow itself has been doing server-side rendering since day one and is still heaps and bounds more usable than WhateverTheHellIsTrendingOnHn.js-based single page isomorphic rich web applications.
It might be my age showing, but, while completely agreeing with you on "progressive enhancement all the way", I find that too freakin' much resources nowadays are spent doing and re-doing and re-inventing something that was working fine in the first place.