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

121–130 of 135 posts

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

#121

Post by batista »

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…

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?

Sure.

1) Client side UI frameworks are still immature. For example Backbone is minimal, while Ember is more featured but with bad documentation and not proven yet. Big frameworks with UI widgets never caught on and are too restrictive. GWT is also on the down and out, etc...

2) Same goes for the tools you need for debugging, unit testing, automation, etc. Nowhere as complete as the server side tools that have been honed for 10+ years.

3) Client experience can be extremely different, when JS performance differs widely between Firefox, Chrome, Safari and IE versions. Not to mention not everybody supporting the history state API.

4) JS performance for long running pages can also vary, due to memory management.

and it can't be close to as flexible (you don't have a model of state on the client to perform logic with)

And on the client you don't have a model of the server (where the actual data are and where the actual actions are performed) to perform logic with.

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

#122

Post by batista »

arturadib wrote: post #52
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…

DHH - if you guys keep working so hard on your custom platform one day you just might be able to reproduce the client-side JSON+JavaScript stack! Keep up the hard work!

And you work for "Mozilla Labs"? As a volunteer, or do they go ahead and hire nerds with no manners and silly notions about entitlement and technology?

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

#125

Post by laughinghan »

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…

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

To take things to the extreme, if you chose to write Basecamp Next in pure x86 assembly (for speed, of course), I think we'd all agree that the code would be much more prone to maintainability problems. Similarly, it is plausible that choosing to write Basecamp Next entirely with pjax+backend MVC+granular key-based caching could be more prone to maintainability problems. Not that I have any particular reason to believe it will, but we're wondering if there are any particular reasons you believe it won't?

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

#126

Post by andybak »

MatthewPhillips wrote: post #38
latch wrote: post #29

Earlier quoted context omitted.

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

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.

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.

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

#127

Post by dmbaggett »

nate wrote: post #118
eik3_de wrote: post #82

Earlier quoted context omitted.

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.

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

#128

Post by latch »

gabyar wrote: post #65

Is Stacker a proprietary 37 Signals thing? It doesn't seem to pop up after several search attempts.

yes, the blog post was quite clear that it's built in-house, with no plans to open source it since it isn't a generic solution (it's purpose-built with Basecamp in mind).

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

#129

Post by nkohari »

brunoc wrote: post #53
MatthewPhillips wrote: post #39

Earlier quoted context omitted.

Double work.

Not with Rails, afaik. Assuming the routes are consistent, you simply add a 'respond' for JSON and send the relevant chunk of the model. Easy as pie.

That assumes, of course, that the viewmodel used to render the server-side view is identical to the model you'd return serialized into JSON. That's mostly true, but not always.

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

#130

Post by dhh »

laughinghan wrote: post #125
dhh wrote: post #105

Earlier quoted context omitted.

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…

"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." To take things to the extreme, if you chose to write Basecamp Next in pure x86 assembly (for speed, of course), I think we'd all agree that the code would be much more prone to maintainability problems. Similarly, it is plaus…

Because neither of those elements have any bearing on maintainability beyond what is customary for a Rails application. The wonders of pjax is that it doesn't require you to change your application style and structure at all, so it has zero impact on maintainability.

The granular caching scheme is similarly just a fragment caching setup using key-based expiration. Nothing new here, just that we used it to full effect.

So you're free to claim that writing Ruby on Rails applications are somehow inherently hard to maintain, but you'd be fighting against 8+ years of evidence to the contrary. Versus, you know, a very short amount of comparable evidence for JavaScript MVC applications based on current, recent frameworks.

Post reply on HN