Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

37signals.com

Post reply on HN
Print view View original

101–110 of 135 posts

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

#101

Post by mhartl »

dhh wrote: post #44
jashkenas wrote: post #24

This is all fascinating ... but does it feel like a sustainable approach going forward, or more like a turbo-charged horse and buggy? Developer happiness aside -- there are plenty of folks who like JavaScript just as much as Ruby -- and assuming that we're talking about an non-public-facing app (like Basecamp Next), is there still an argument that can be made in favor of doing your UI on the server side? Even just in…

I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page, not just a single-page JS app). I'm sure Flash or Silverlight or other RIA people would argue that anything that's not a compiled native experience isn't as flexible or as fast as…

app that feels like a web page, not just a single-page JS app

I think this is a key point and is one reason that server-side approaches will be relevant for a long time to come. Some applications, such as Gmail and Pivotal Tracker, feel a lot like desktop apps, and heavy use of client-side code is a necessity in these cases. But many—I'd argue the vast majority—of web applications produce a better user experience when they feel like ordinary web pages. I don't see that changing any time soon.

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

#102

Post by stock_toaster »

jashkenas wrote: post #85
romaniv wrote: post #80

Earlier quoted context omitted.

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 c…

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.

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

#103

Post by VMG »

hollerith wrote: post #74
VMG wrote: post #46

Earlier quoted context omitted.

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.

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

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

#105

Post by dhh »

iamgilesbowkett wrote: post #97
dhh wrote: post #64

Earlier quoted context omitted.

In terms of client-side MVC vs server-side renderings, the ration is more like 90/10 or 95/5. We have one major section that's all client-side MVC, which is our calendar. We have one tiny section as well, which is a little invite widget. Everything else is server-side renderings. To me that's like how we in the past used Flash to play sounds in Campfire. Or reimplemented a poller in Erlang. Or use nodejs for the deve…

In terms of client-side MVC vs server-side renderings, the ratio is more like 90/10 or 95/5. DHH, I think you misunderstood here; I believe Jeremy's referring to the blog post where you said Basecamp Next had almost as many lines of CoffeeScript as lines of Ruby. I think that's where the 50/50 number came from. I'm less curious about the performance here than I am about the maintainability. I saw a tweet where somebo…

On 50/50, yes, we write lots of JavaScript for Ajax. We've done that since 2005 with Tada list. The debate here is over whether going client-side MVC for everything is a pleasant experience. I contend that it is not.

The maintainability story with pjax+caching is exactly the same as its always been with a Rails app. We just celebrated 8 years with Basecamp. That's a pretty good run.

You can write shit, unmaintainable code in anything, but to point at pjax and granular key-based caching schemes as somehow specifically prone to this? What? That doesn't make any sense to me.

We also had a swanky in-house client-side MVC framework cooking with Cinco. We used it once for Basecamp Mobile and while it was a good experience and the end result was great, it did little to sway my thinking on client-side MVC being a step forward in programming happiness (one of the key things I evaluate platforms by).

Again, it's perfectly fine to have a different opinion. I don't like the aesthetics nor the sensibilities of Python code much, but I certainly respect that people can make cool shit with it and even that they might enjoy the process.

The hoopla here is over the terribly flawed notion that client-side MVC is somehow The Future of web development and if you don't follow that pattern, you're living in The Past. Ha.

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

#106

Post by Void_ »

irahul wrote: post #100
Void_ wrote: post #99

Earlier quoted context omitted.

I think in most cases it will be more than 100ms. Much more than that. Just latency to basecamphq.com is 350ms from here (Europe.)

OP is measuring page render time on the server. Network latency is variable, and there isn't much one can do to fix it.

What does the user care if the time is spent rendering, transmitting or baking cookies?

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

#107

Post by mark_l_watson »

irahul wrote: post #96
edw519 wrote: post #68

I love posts like this, not just for what OP has done, but for what you guys have to say about it. I'm continually asking myself 3 questions: 1. Should I do it on the client or the server? 2. What should be travelling between the client and the server? 3. Based on the answer to #2, what else do I need on the client? Even though I've read all your great discussion points, I'm not sure I'm that much smarter. But it's n…

> 1. Should I do it on the client or the server? I think most applications use both client and server components. If your question is more on the lines of which one plays a major role, it depends mostly on the app. GMail won't be half as good without all the JS magic, but again, I assume it also has a heavy server component. > 2. What should be travelling between the client and the server? If you need any client side…

Thanks you for the links. I found a simple Rails pjax app and I am going through the code right now: https://github.com/edison/pjax-rails-sample

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

#108

Post by poutine »

Void_ wrote: post #106
irahul wrote: post #100

Earlier quoted context omitted.

OP is measuring page render time on the server. Network latency is variable, and there isn't much one can do to fix it.

What does the user care if the time is spent rendering, transmitting or baking cookies?

Whether the data is sent via HTML or JSON it will still incur the network latency.

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

#109

Post by Joeri »

irahul wrote: post #96
edw519 wrote: post #68

I love posts like this, not just for what OP has done, but for what you guys have to say about it. I'm continually asking myself 3 questions: 1. Should I do it on the client or the server? 2. What should be travelling between the client and the server? 3. Based on the answer to #2, what else do I need on the client? Even though I've read all your great discussion points, I'm not sure I'm that much smarter. But it's n…

> 1. Should I do it on the client or the server? I think most applications use both client and server components. If your question is more on the lines of which one plays a major role, it depends mostly on the app. GMail won't be half as good without all the JS magic, but again, I assume it also has a heavy server component. > 2. What should be travelling between the client and the server? If you need any client side…

More important than whether to send html, json or xml is WHEN to send that content. People underestimate just how painful latency is to the user because they're sitting right next to their web server. Digg takes 15 times longer to load from bangalore than from california (see http://www.slideshare.net/kkjjkevin03/geographic-distributio... ). The thing that client-side rendering allows is caching your application UI in the browser and on the CDN. The server only gets contacted when it's absolutely necessary.

If you go mobile, it gets worse, because sometimes you'll lose the network for a few minutes, or even a few hours. Building a web app that keeps running in that scenario is possible, but only by embracing a client-side philosophy. In my personal opinion, mobile is going to be the dominant way that people connect, and the network is not going to be robust enough to render mobile web apps on the server.

Post reply on HN