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

81–90 of 135 posts

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

#81

Post by alinajaf »

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, I'm also none the wiser having read the OP and the comments here.

I'm quite used to a fully server side model so I'm currently experimenting with a few side projects to see just how much I can put into the client without going anywhere near the server.

I think once I've pushed it to its limits I can start working my way back to the server and achieve a good balance. None of this would of course be bearable without coffeescript and a nice js framework like backbone.

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

#82

Post by eik3_de »

ColinCampbell wrote: post #48
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…

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?

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

#83

Post by ThomPete »

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…

I think that is kind of a strawman.

Neither flash, flex or silverlight are being pushed these days for these kind of services.

Like the new design and with that I don't mean so much how it looks but more how it looks like it's going to feel using it.

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

#84

Post by Joeri »

jondot wrote: post #70
Joeri wrote: post #60

Earlier quoted context omitted.

You can still do unit testing of your client-side code if you wrap everything in components that separate state from rendering. The rendering itself you can only test with a human looking at the page anyway (or by comparing to reerence renderings). Extjs uses this approach. I can easily unit-test my forms written on top of extjs. Fundamentally this is a bikeshedding debate. Whether you're programming on the client or…

Great! You may have put it better than me with the closer to server - closer to user analogy. So to complete my goal I'll ask a question. You already are at the server. It cost you almost nothing to manage yourself there (monitor, analyze, etc). Do you have the resources to handle the complexity of being closer to the user? Is a "true" client side SPA worth it over what 37 are doing? In terms of value for development…

I used to build stuff on the server, then i switched to extjs, with the server only exposing a bunch of json-rpc web services. It's not as big a deal as people paint it out to be. Extjs abstracts away browser differences well enough that i rarely come across issues that aren't reproduceable for me. If they're reproduceable for me in my browser, they're easy to fix.

Now, extjs is a DSL, it's closer to flex development than to traditional web development. It has a learning curve with a pay-off at the end, and the pay-off is easier ui development. If you're building ui the traditional way, but client-side, ymmv. Still, anything to do with rendering glitches is something you'll have to debug by eyeballing it, regardless of where you render your ui. There's no way of automatically logging misplaced floats.

P.S. There's also less to monitor. Typically you'll monitor for performance and security. Performance depends on the browser and pc specs, not the server's load, and security has nothing to do with the client. So, really, there's just not much to monitor. You can attach error handlers to automatically report exceptions to the server, but i've not had a need.

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

#85

Post by jashkenas »

romaniv wrote: post #80
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…

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.

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

#87

Post by dhh »

MattRogish wrote: post #79
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…

Hi DHH, Huge fan of your work. Been in love with Rails since the pre 1.0 days. Our team internally (we have an existing Rails 3 app that we want to improve rendering performance) has been going back and forth with "Rails should emit JSON and render client side" and "We should be smarter about caching and AJAX-ifying our pages". Your post has given more ammunition to the Rails-only side, so that is really awesome; tha…

Matt, I don't think there's all that much difference in money spent (you still need to buy servers either way and you still need to cache even if you return JSON). We crank out functionality faster when it can be done server-side because the development experience is better and because Ruby still beats even CoffeeScript (although not as thoroughly as it used to beat vanilla JavaScript) for productivity.

I find the complexity needed in having MVCs on both client and server side to be the main problem. Especially since much of what applications like Basecamp are not all that heavy on the UI-interaction. A few bits are, like a calendar, so we use it there.

But obviously you can make it work either way. Just like Facebook manages to make PHP work. And some crazy kids still use Java. You should pick a development environment and style that fits your brain and your sensibilities. If you think client-side development is lovely, then by all means, go to town. Some people even think JavaScript is still as well as Ruby and that you don't even need CoffeeScript -- peace be with them.

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

#88

Post by romaniv »

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…

is there still an argument that can be made in favor of doing your UI on the server side?

Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website.

And this is just the stuff relevant to internal (non-public) websites. You can argue that all of this can be achieved with JavaScript heavy clients, but in reality, it's just isn't. It's not something you get by default, it's tons of extra work, and most people don't do that work.

Even just in principle, it can't possibly be close to as fast (client-side can render optimistically, where possible), and it can't be close to as flexible (you don't have a model of state on the client to perform logic with).

In principle, server-side rendering can allow you to share pre-rendered components between thousands of users saving everyone tons of work. In practice, rendering on the server side is just string concatenation and is insignificant compared to things like running SQL quires, which you'll have to do anyway.

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

#89

Post by iamleppert »

Awesome, very interesting article that shows you don't always have to go full client side to get a snappy app.

However, I do agree with another poster about this being a turbo charged horse and buggy. You can't, for example, deploy the app to a static CDN, or serve templates from a CDN. Templates can't be cached on the client, so you've developed what is essentially an elaborate partials caching infrastructure that is likely very brittle and must be watched over closely to maintain speed benefits (keeping all those things in mind when content changes -- what to throw out and what to keep, etc).

Also, by delivering HTML you're limiting your presentation to browser-only devices, at least with this app. I know basecamp has a JSON API, and at that point, why didn't you just do a traditional client side app I wonder? I think the answer rests in the fact that you preferred the "niceness" of server side development, which is arguably more mature than client side at the present time. If that's the only benefit, in a few years, do you think that advantage will hold true?

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

#90

Post by asaeidi »

MatthewPhillips wrote: post #9
mattmanser wrote: post #3

Hmm, degraded development experience of doing everything on the client? Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem. Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some s…

Stacker sounds like AJAX as it was done in 2006, except trigger by pushState. Maybe I'm misunderstanding it though. I'd be curious what the performance penalty is on mobile.

Seems it's a highly refined version of what was done in the "old" days. I remember doing something similar for an old project in ASP.NET. (Well more similar to pjax)

As to performance on mobile, i think it might all depend on how large the html fragments are.

Post reply on HN