5 ms·

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: every

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: everything on mobile, desktop clients not close to a server), needing to go back to the server to render will ruin the perceived performance of your app. Well-written applications running on the client can take a change and optimistically render that before the change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.

romaniv 15y ago
The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. It still needs to go back to the server to fetch new data. And it's not like rendering on the client side is instant and free. There are plenty of JS-heavy websites that visibly lag during UI operations because of all the stuff that goes on during "rendering" (in quotes, because it usually includes large chunks of business logic).
- jashkenas 15y ago
  There are smart ways to render client-side UI, and there are not-so-smart ways. http://jsperf.com/dom-vs-innerhtml-based-templating/350 http://jsperf.com/dom-vs-innerhtml-based-templating/350 If you want to use a decent library, you can rest assured that your client-side templates will render far faster than the Ruby version of the same HTML.
  - stock_toaster 15y ago
    Even considering I do not have an 8 core machine with 32 GB of ram sitting on my lap (or in my pocket)? I realize that ruby is significantly slower than v8/JägerMonkey/Tracemonkey/etc, but is it so easy to discount the significant disparity between the average compute power of a server vs mobile/laptop? I think a stronger counter argument would be flexibility, smaller http responses (and thus less latency), and possibly an argument that it is simpler or more straightfoward, in favor of client-side javascript templating/rendering, but rendering speed? Not so sure.
eik3_de 15y ago
I was just looking at the base latency for 37s servers: curl -sIX HEAD -o /dev/null -w "%{time_total} s\n" https://asset1.basecamphq.com/rev_7ab3626/images/indicator.gif gives me about 600 ms min. which is quite high compared to e.g. https://encrypted.google.com/textinputassistant/tia.png https://encrypted.google.com/textinputassistant/tia.png (45 ms min.) Ping to 37s (204.62.114.1) is only about 109 ms, so it looks like the SSL handshake is very slow?
- nate 15y ago
  One thing I've noticed is that Google likes to use RC4_128 as their encryption method for SSL. Most people just pick AES_256_CBC like 37s has. RC4_128 is so much faster in tests we've run. Of course, there's a possible security trade off, sort of. RC4, I believe from reading, is still plenty strong when it's properly implemented.
  - dmbaggett 15y ago
    I've definitely observed this performance difference, and it is quite significant. However, the new AES-NI instructions in more recent Intel chips may lessen the performance difference over time, as more users buy machines with these chips. (Of course, that won't help mobile devices yet, and it's possible that one could equivalently speed up RC4 with those instructions as well.) But I know the latest OpenSSL does have an AES implementation that uses AES-NI when those instructions are supported.

romaniv 15y ago

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. It still needs to go back to the server to fetch new data. And it's not like rendering on the client side is instant and free. There are plenty of JS-heavy websites that visibly lag during UI operations because of all the stuff that goes on during "rendering" (in quotes, because it usually includes large chunks of business logic).

jashkenas 15y ago
There are smart ways to render client-side UI, and there are not-so-smart ways. http://jsperf.com/dom-vs-innerhtml-based-templating/350 http://jsperf.com/dom-vs-innerhtml-based-templating/350 If you want to use a decent library, you can rest assured that your client-side templates will render far faster than the Ruby version of the same HTML.
- stock_toaster 15y ago
  Even considering I do not have an 8 core machine with 32 GB of ram sitting on my lap (or in my pocket)? I realize that ruby is significantly slower than v8/JägerMonkey/Tracemonkey/etc, but is it so easy to discount the significant disparity between the average compute power of a server vs mobile/laptop? I think a stronger counter argument would be flexibility, smaller http responses (and thus less latency), and possibly an argument that it is simpler or more straightfoward, in favor of client-side javascript templating/rendering, but rendering speed? Not so sure.

eik3_de 15y ago

I was just looking at the base latency for 37s servers: curl -sIX HEAD -o /dev/null -w "%{time_total} s\n" https://asset1.basecamphq.com/rev_7ab3626/images/indicator.gif gives me about 600 ms min. which is quite high compared to e.g. https://encrypted.google.com/textinputassistant/tia.png https://encrypted.google.com/textinputassistant/tia.png (45 ms min.) Ping to 37s (204.62.114.1) is only about 109 ms, so it looks like the SSL handshake is very slow?

nate 15y ago
One thing I've noticed is that Google likes to use RC4_128 as their encryption method for SSL. Most people just pick AES_256_CBC like 37s has. RC4_128 is so much faster in tests we've run. Of course, there's a possible security trade off, sort of. RC4, I believe from reading, is still plenty strong when it's properly implemented.
- dmbaggett 15y ago
  I've definitely observed this performance difference, and it is quite significant. However, the new AES-NI instructions in more recent Intel chips may lessen the performance difference over time, as more users buy machines with these chips. (Of course, that won't help mobile devices yet, and it's possible that one could equivalently speed up RC4 with those instructions as well.) But I know the latest OpenSSL does have an AES implementation that uses AES-NI when those instructions are supported.