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

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

#131

Post by jcoffey » Sun, Feb 19, 2012, 2:10 PM UTC

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…

I'd be curious as to how much benefit could be derived by moving the business logic in the server side MVC to the database in the form of triggers, stored procedures etc. Seems like that's the really natural place for some of the functionality, such as validation, that can't be implemented safely client-side.

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

#132

Post by jcoffey » Sun, Feb 19, 2012, 2:14 PM UTC

irahul wrote: post #113

Void_ wrote: post #106

Earlier quoted context omitted.

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

Well the point is that by doing rendering on the client side you get most of the latency issues out of the way on first load and actually have a lot more control over its effects on the user even after that (e.g. you have the option of syncing with the server in the background).

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

#133

Post by cicloid » Sun, Feb 19, 2012, 5:33 PM UTC

dhh wrote: post #5

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…

We've found that the additional overhead of sending HTML vs JSON is negligible in most cases. The additional speed gained by just sending JSON across is not worth the programming enjoyment hit of doing everything client-side. When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you…

How about HTML versus MessagePack ( http://msgpack.org/ )?

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

#134

Post by sourcefrog » Tue, Feb 21, 2012, 4:14 AM UTC

romaniv wrote: post #88

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…

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

You can manipulate the page url/browser history from js, and you can use the url to set the application state. History and bookmarks work perfectly well in gmail, for example.

This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. Otherwise, you're doing whole page loads on every request.

js works pretty well on modest smartphones, at which level network latency is usually the major concern...

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

#135

Post by romaniv » Wed, Feb 22, 2012, 6:54 PM UTC

sourcefrog wrote: post #134

romaniv wrote: post #88

Earlier quoted context omitted.

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…

> 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. You can manipulate the page url/browser history from js, and…

This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow.

It should not be similar. There is a huge architectural difference between the two approaches. In server-side approach you're adding caching or prefetch to an already working application that has established and working URLs. With client-side approach, you need to implement adapters that transform URL information into the client state that is normally achieved by a series of UI operations and AJAX calls. Then you need to add new code to generate URLs and manipulate history.

The beauty of caching or partial page fetches is that they are generic. History manipulation is not.

js works pretty well on modest smartphones, at which level network latency is usually the major concern...

The last time I tried to browse on Kindle, it choked and died on most JS heavy websites. When 500MHz processor is not fast enough to browse the web, to me, that's a problem.