How Basecamp Next got to be so damn fast without using much client-side UI

Re:How Basecamp Next got to be so damn fast without using mu... by ColinCampbell on Friday February 17, 2012 @11:50AM (#3603952)

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.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by eik3_de on Friday February 17, 2012 @01:30PM (#3604411)

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?

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by nate on Friday February 17, 2012 @07:33PM (#3605565)

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.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by dmbaggett on Saturday February 18, 2012 @09:50AM (#3606676)

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.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by romaniv on Friday February 17, 2012 @01:27PM (#3604397)

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

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by jashkenas on Friday February 17, 2012 @01:36PM (#3604439)

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.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by stock_toaster on Friday February 17, 2012 @03:26PM (#3604847)

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.

[ Parent | on HN ]