3 ms·
Just because client-side rendering did not work well for Twitter for a variety of reasons, does not mean it is subpar to server-side rendering in all cases. Per
by chime 14y ago
Just because client-side rendering did not work well for Twitter for a variety of reasons, does not mean it is subpar to server-side rendering in all cases. Performance-wise, if server_json_generate + json_download + client_render_json_to_html < server_html_generate + html_download + client_render_html, you can certainly go with client-side rendering.
In Twitter's case, client-side rendering was slow while server-side wasn't. In LinkedIn's case, html_download was slow while client_render_json_to_html wasn't. Performance aside, there are numerable reasons to go either away, all of which vary from project to project.
Having Worked with CoffeeScript + Twitter Bootstrap + BackboneJS/Underscore + LessCSS for some time now, I know I will not willingly go back to the old server-side ways unless there is a major reason to. Working fully client-side to make UI and relying on REST API / JSON is wonderful experience, especially when the app feels so responsive.
- rhizome 14y agoCan we assume that degradability isn't a concern for you? Accessibility?
- chime 14y agoDegradability is not a concern. Accessibility is, and client-side rendering does not mean no accessibility.
- jameswyse 14y agoWhat about SEO? I've noticed a lot of these sites that are rendered client-side start with very little content in the HTML, doesn't this mean the search engines can't read the content?
- cynwoody 14y agoAccording to this other LinkIn blog post, http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates http://engineering.linkedin.com/frontend/leaving-jsps-dust-m... (look for SEO in the comments), they detect cases where the client can't or won't do JS and perform the rendering server-side.