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

111–120 of 135 posts

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

#111

Post by iamgilesbowkett »

dhh wrote: post #105
iamgilesbowkett wrote: post #97

Earlier quoted context omitted.

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…

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

I'd like to hear more about this, ideally in a blog post or two. I think a lot of people were waiting for Cinco's release, certainly I was, because we wanted to see what you'd do with it. The fact that you have Basecamp Next running without it certainly says something, but I'd be a lot more interested to find out what the specific tradeoffs were.

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

#112

Post by iamgilesbowkett »

mhartl wrote: post #101
dhh wrote: post #44

Earlier quoted context omitted.

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

yeah, I agree. actually I don't know if I'd agree on the "vast majority" part, but the question of "is client-side MVC The Future?" can get kind of silly and messianic, while the question of "is client-side MVC A Future?" is undoubtedly yes.

there's a lot you can do browser-side these days which would be insanely masochistic without client-side MVC, but that doesn't change the fact that lots of very useful apps run on the ordinary web pages model.

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

#113

Post by irahul »

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?

I am not sure what point you are trying to make.

1. Controlling how long page render takes at the server is under the developer control.

2. The size of network load is under developer control.

3. Client side optimization are under developer control.

OP is saying 1 is low; 2 is low(not much difference between html load and json load); and 3 is low as there isn't much going on at client side.

Other than that:

1. User network is slow, hence leading to large load times.

Go bake potatoes - can't help.

2. User is located at a distant location from the server.

If the user is part of a market which the company sees as profitable, the server can be mirrored.

Or else you can go bake potatoes.

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

#114

Post by tortilla »

mark_l_watson wrote: post #107
irahul wrote: post #96

Earlier quoted context omitted.

> 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

Nice screencast too:

http://railscasts.com/episodes/294-playing-with-pjax

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

#115

Post by agilebyte »

zaidf wrote: post #69
jonknee wrote: post #43

Earlier quoted context omitted.

That's nonsense, the same issue would apply on the server side templates. If you go around messing with DIVs without an idea of the consequences, you will get in trouble regardless of your templates being on the server or client. If you try to have the designer do a redesign without testing the application afterwards, you're always in for trouble.

you will get in trouble regardless of your templates being on the server or client My view is that you will get in significantly less trouble because manipulating an HTML template that is rendered on server side is much easier to manage and adapt to a new design than finding nitpick jquery selectors across the app that depend on a specific div structure. Btw, my post doesn't imply anywhere that a designer should rede…

Rather than "finding nitpick jquery selectors" I use a client side framework (backbone.js) with a lot of Views which makes my development faster vs using server side templating, so I cannot share your opinion.

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

#116

Post by irahul »

mark_l_watson wrote: post #107
irahul wrote: post #96

Earlier quoted context omitted.

> 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

Looking at the rails pjax_rails gem https://github.com/rails/pjax_rails I see it automatically patches layout to return false when the request is pjax.

https://github.com/rails/pjax_rails/blob/master/lib/pjax.rb#...

    layout ->(c) { pjax_request? ? false : 'application' }
So in the sample app you pointed out:

    def show
      @post = Post.find(params[:id])

      if pjax_request?
        render layout: false
      else
        respond_to :html
      end
    end
is the same as:

    def show
      @post = Post.find(params[:id])
    end
Also, pjax-rails converts the following selection to pjax:

https://github.com/rails/pjax_rails/blob/master/lib/assets/j...

    $('a:not([data-remote]):not([data-behavior]):not([data-skip-pjax])')
I was a bit baffled by the example app since it didn't appear to be doing any pjaxy stuff, but rails being opinionated, I see all links are pjax(except the not classes show above), and layout is turned off for pjax requests.

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

#117

Post by mark_l_watson »

irahul wrote: post #116
mark_l_watson wrote: post #107

Earlier quoted context omitted.

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

Looking at the rails pjax_rails gem https://github.com/rails/pjax_rails I see it automatically patches layout to return false when the request is pjax. https://github.com/rails/pjax_rails/blob/master/lib/pjax.rb#... layout ->(c) { pjax_request? ? false : 'application' } So in the sample app you pointed out: def show @post = Post.find(params[:id]) if pjax_request? render layout: false else respond_to :html end end is…

I put some debug printouts in his example notes controller and it seemed to be setting the no layout rendering option correctly, but as you say, the checks in the controller may be redundent. Anyway, I am planning on giving pjax a very good look: I find doing a lot of client side coding to be tedious and is something to be minimized.

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

#118

Post by nate »

eik3_de wrote: post #82
ColinCampbell wrote: post #48

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

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.

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

#120

Post by gambler »

arijo wrote: post #72
dhh wrote: post #44

Earlier quoted context omitted.

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…

Also, bashing javascript client-side frameworks makes great link bait.

Who's bashing what? The author simply described some caching techniques and got a tsunami of hatred from JavaScript, ahem, fans in response.
Post reply on HN