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

91–100 of 135 posts

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

#91

Post by dgregd »

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…

"but does it feel like a sustainable approach going forward"

Maybe you are right. However it it too early to do a big rewrite in JS. There are many JS frameworks but no clear leader. I am sure that in 3 years decision how to design you client side web app will be much easier.

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

#92

Post by asaeidi »

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…

Also what about deployments/bug fixes? Seems if you need to make changes to the html fragments you'd have to do a full app deploys every time. Versus making changes to specific JS file and uploading it.

Personally that's why i like this whole shift to single page apps. Just as we've decoupled certain aspects of the server-side development, we can do the same with the UI.

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

#93

Post by MattRogish »

dhh wrote: post #87
MattRogish wrote: post #79

Earlier quoted context omitted.

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

DHH,

Thanks for the reply. Look forward to using Basecamp NEXT (we use all the 37 signals products here) and seeing the evolution of your process as you continue.

-- Matt

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

#94

Post by joe2b »

jashkenas wrote: post #62
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…

By "sustainable" I'm getting at the point that if you're already doing 50/50 Ruby/JavaScript ... it makes you wonder which direction that ratio will tend to go in the future. Will Basecamp Next Next still be rendered as chunks of HTML that are sent over the wire to be inserted into specific spots on the page in 2015? Either way, I'm very much looking forward to using the new version.

I'd argue server side performs much faster than client side.

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

#96

Post by irahul »

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 processing or are using a framework which works on raw data(backbone.js), then json/xml/...; or else if your goal is to run the app without reloading unnecessary parts, html is a better idea.

> 3. Based on the answer to #2, what else do I need on the client?

I am not sure what you are looking for here, but if your goal is to make a responsive app, there are some basic things to take care of.

Have bookmarkable links and don't break the back button. Doing that is breaking the base paradigm, and plain ajax does that.

Use something that provides bookmarkable links, and doesn't break the back/forwrad button; and at the same time, doesn't reload the whole page when only a small portion of the page needs reloading.

pjax is one such solution - the 37signals guys investigated it, then went with their home grown solution, but I think pjax will work just fine for majority of use cases.

The trick to pjax is serving content without layout if it is a pjax reques; with layout otherwise. There is nothing you can't handroll, but 1) why would you want to? 2) pjax uses pushState to preserve links and back button behavior.

Here is the pjax code:

https://github.com/defunkt/jquery-pjax

And here is a gist in Flask/Python which shows conditionally including the layout:

https://gist.github.com/830fc28c680e77759b4b

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

#97

Post by iamgilesbowkett »

dhh wrote: post #64
jashkenas wrote: post #62

Earlier quoted context omitted.

By "sustainable" I'm getting at the point that if you're already doing 50/50 Ruby/JavaScript ... it makes you wonder which direction that ratio will tend to go in the future. Will Basecamp Next Next still be rendered as chunks of HTML that are sent over the wire to be inserted into specific spots on the page in 2015? Either way, I'm very much looking forward to using the new version.

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 somebody said he'd done things the same way and encountered a maintenance nightmare -- he mentioned nested caching and pjax specifically -- but without context or detail, I'm taking that with a grain of salt. I think disregarding it completely would be a mistake too, though.

It's also kind of tautological that DHH is going to have a more pleasant experience developing in Rails than he is in other frameworks. ;-)

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

#98

Post by roc »

latch wrote: post #36
roc wrote: post #28

Earlier quoted context omitted.

> "I really don't understand what's so compelling - unless those exact same actions are actually (YAGNI) used as endpoints of a web service" Well of course it's not going to appear all that compelling after you rule out the most compelling use case .

Hey, I totally agree that if your actions are gonna be consumed by clients other than your own UI, it makes total sense. However, I've seen people [strongly] advocating this approach even when this isn't the case..that's what I don't get.

Well there are other benefits. [1]

Though I suspect you're just talking about cases that are best chalked up to: there's no accounting for the logic of the illogical.

[1] If you want to ensure a separation between display code and business logic, it's not a bad way to draw a line; some heavily data-driven problems do tangibly benefit from fetching JSON and formatting on the client; solutions that have multiple views on essentially the same data sets benefit in much the same way that solutions with multiple clients benefit; etc.

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

#99

Post by Void_ »

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 in most cases it will be more than 100ms. Much more than that. Just latency to basecamphq.com is 350ms from here (Europe.)

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

#100

Post by irahul »

Void_ wrote: post #99
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…

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.
Post reply on HN