5 ms·

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a

by latch 15y ago

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a cached html fragment is the exact same amount of work on the server as returning a cached-json value. Plus, it's less work for the client to drop the already-rendered html into a container than to have to bind the model to the template. I feel like I'm being super dumb, but to me this approach is going to result in faster rendering.

MatthewPhillips 15y ago
Don't overlook the bandwidth overhead of html fragments vs. json snippets. That issue is magnified on mobile. Additionally, if you are doing small updates the DOM API is faster than injecting .innerHTML. I think this has changed in recent years and .innerHTML might have caught up for larger nodes. I personally still use the DOM API because it encourages more simplistic layouts.
- danmaz74 15y ago
  IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...
- andybak 15y ago
  Also remember that it's usually latency and connections that kills mobile performance. I've also found the actual data transfer to be fairly good compared to your average domestic DSL.
VMG 15y ago
A small change in state can cause a large change in the view. When the server renders the html, it has to send all the portions of the view that have changed. When rendering client-side, the server only needs to send the portion of the state that changed.
- latch 15y ago
  Good point, thanks. So it potentially provides you with opportunities for further optimization. I guess the message from DHH is that they hit their performance targets, so this would be an unnecessary optimization (and I'm tempte to say "non-trivial to implement"..but now I know I'm being biased..)
- hollerith 15y ago
  >A small change in state can cause a large change in the view. It can, but maybe there is a way to write Basecamp so that large changes in view are rare.
  - VMG 15y ago
    That is limiting the application though. With client-side rendering you can have large view changes with little state change.
ColinCampbell 15y ago
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.
Joeri 15y ago
The big advantage of client-side rendering is that you can break out of the mindset of outputting blobs of html from templates. You can think in terms of ui elements and the business logic that drives their creation and updates. Once in that mindset, you can think about how to prefetch data and store it locally to not have to go to the server for every ui update. If you're doing it right, many actions don't require going to the server at all.

by latch 15y ago

MatthewPhillips 15y ago

Don't overlook the bandwidth overhead of html fragments vs. json snippets. That issue is magnified on mobile. Additionally, if you are doing small updates the DOM API is faster than injecting .innerHTML. I think this has changed in recent years and .innerHTML might have caught up for larger nodes. I personally still use the DOM API because it encourages more simplistic layouts.

danmaz74 15y ago
IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...
andybak 15y ago
Also remember that it's usually latency and connections that kills mobile performance. I've also found the actual data transfer to be fairly good compared to your average domestic DSL.

VMG 15y ago

A small change in state can cause a large change in the view. When the server renders the html, it has to send all the portions of the view that have changed. When rendering client-side, the server only needs to send the portion of the state that changed.

latch 15y ago
Good point, thanks. So it potentially provides you with opportunities for further optimization. I guess the message from DHH is that they hit their performance targets, so this would be an unnecessary optimization (and I'm tempte to say "non-trivial to implement"..but now I know I'm being biased..)
hollerith 15y ago
>A small change in state can cause a large change in the view. It can, but maybe there is a way to write Basecamp so that large changes in view are rare.
- VMG 15y ago
  That is limiting the application though. With client-side rendering you can have large view changes with little state change.

ColinCampbell 15y ago

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.

Joeri 15y ago

The big advantage of client-side rendering is that you can break out of the mindset of outputting blobs of html from templates. You can think in terms of ui elements and the business logic that drives their creation and updates. Once in that mindset, you can think about how to prefetch data and store it locally to not have to go to the server for every ui update. If you're doing it right, many actions don't require going to the server at all.