4 ms·

> That's good news from a bandwidth point of view, an environmental point of view, and, if you're clever about how you code it, a rendering speed point of view

by ssmoot 12y ago

> That's good news from a bandwidth point of view, an environmental point of view, and, if you're clever about how you code it, a rendering speed point of view because you only have to replace the content in some DOM nodes rather than repainting the entire template. It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering). Also, never experienced an application where parsing a blob of JSON and manipulating the innerText and values of HTMLElements with JavaScript was more efficient than setting innerHTML.

onion2k 12y ago
It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering) The difference isn't between sending a couple of extra packets versus rendering on the client. It's between rendering on the server PLUS sending a couple of extra packets versus rendering on the client. You have to do the rendering somewhere. Assuming the code that does the rendering is essentially the same whether it's server-side or client-side, the only difference is sending the extra structural layout data when you render on the server. For most sites it'll make no real difference but if you're at Facebook scale I'd guess a couple of extra packets really adds up, especially considering you could cache the client-side templates between sessions.
- ssmoot 12y ago
  I should have mentioned the assumption you'd be caching the render on the server. My bad. So I imagined it as 1 render vs potentially thousands. Another thing to note: You'd (probably) have to try real hard to find a server side templating solution that would render as slowly and use as much CPU as JavaScript on the client-side.
  - webXL 12y ago
    There's no magic bullet. As soon as your template references user specific (private) data, the caching advantage almost disappears, because each user requires their own cached rendering. You might as well cache it on the client and save the round-trip, and any additional network/server performance issues. Rendering public, read-only content such as a tweet, however, makes total sense to cache on the server.
    - ssmoot 12y ago
      JSON is still rendered. It's not "render or send JSON", it's "render a string that contains formatted display output A, or a string that contains structured data B". Facebook probably requires a lot of per-user effort true. A lot of sites (github for example) probably don't. It's probably limited to a couple areas of the header generally, or an A or B conditional render for an ownership page. There's always exceptions to every rule though.

by ssmoot 12y ago

onion2k 12y ago

It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering) The difference isn't between sending a couple of extra packets versus rendering on the client. It's between rendering on the server PLUS sending a couple of extra packets versus rendering on the client. You have to do the rendering somewhere. Assuming the code that does the rendering is essentially the same whether it's server-side or client-side, the only difference is sending the extra structural layout data when you render on the server. For most sites it'll make no real difference but if you're at Facebook scale I'd guess a couple of extra packets really adds up, especially considering you could cache the client-side templates between sessions.

ssmoot 12y ago
I should have mentioned the assumption you'd be caching the render on the server. My bad. So I imagined it as 1 render vs potentially thousands. Another thing to note: You'd (probably) have to try real hard to find a server side templating solution that would render as slowly and use as much CPU as JavaScript on the client-side.
- webXL 12y ago
  There's no magic bullet. As soon as your template references user specific (private) data, the caching advantage almost disappears, because each user requires their own cached rendering. You might as well cache it on the client and save the round-trip, and any additional network/server performance issues. Rendering public, read-only content such as a tweet, however, makes total sense to cache on the server.
  - ssmoot 12y ago
    JSON is still rendered. It's not "render or send JSON", it's "render a string that contains formatted display output A, or a string that contains structured data B". Facebook probably requires a lot of per-user effort true. A lot of sites (github for example) probably don't. It's probably limited to a couple areas of the header generally, or an A or B conditional render for an ownership page. There's always exceptions to every rule though.