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.
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.
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.
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).
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.
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.
