5 ms·

It's interesting to note that while Twitter has moved away from client side rendering of HTML templates (and is a strong advocate of sending HTML directly down

by karterk 14y ago

It's interesting to note that while Twitter has moved away from client side rendering of HTML templates (and is a strong advocate of sending HTML directly down the wire[1]), LinkedIn mobile app seems to be rendering the template on the client. [1]: http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html http://engineering.twitter.com/2012/05/improving-performance...

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 ago
  Can we assume that degradability isn't a concern for you? Accessibility?
  - chime 14y ago
    Degradability is not a concern. Accessibility is, and client-side rendering does not mean no accessibility.
- jameswyse 14y ago
  What 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 ago
    According 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.
    - Marwy 14y ago
      How do they do that? I can't really figure out anything apart checking user agent (for web crawlers?)
      - heroic 14y ago
        you can simply check for the accepts header.
rhizome 14y ago
I'm a bit bemused that for me, I can't think of an area where LinkedIn is anything more than a straight HTML site. That is, why would they need something like this?
- Domenic_S 14y ago
  Why would they need a template engine? Erm.. because they have more than one user....
  - rhizome 14y ago
    I mean to say that there doesn't seem to be any apparent use of node on LI. Is there a chat facility or something?

by karterk 14y ago

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 ago
Can we assume that degradability isn't a concern for you? Accessibility?
- chime 14y ago
  Degradability is not a concern. Accessibility is, and client-side rendering does not mean no accessibility.
jameswyse 14y ago
What 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 ago
  According 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.
  - Marwy 14y ago
    How do they do that? I can't really figure out anything apart checking user agent (for web crawlers?)
    - heroic 14y ago
      you can simply check for the accepts header.

rhizome 14y ago

I'm a bit bemused that for me, I can't think of an area where LinkedIn is anything more than a straight HTML site. That is, why would they need something like this?

Domenic_S 14y ago
Why would they need a template engine? Erm.. because they have more than one user....
- rhizome 14y ago
  I mean to say that there doesn't seem to be any apparent use of node on LI. Is there a chat facility or something?