Hacker News Reader

Comment by latch | Hacker News Reader

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.

View on HN

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.

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 (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?

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

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

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.

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.

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.

IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...

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.

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.

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

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

That is limiting the application though. With client-side rendering you can have large view changes with little state change.

Reply on news.ycombinator.com