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

21–30 of 135 posts

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

#21

Post by dos1 »

latch wrote: post #19

I have to say, reading this made my day. I've been feeling such a push towards client-side templates lately, that I felt like it was just me that didn't get it. I really don't understand what's so compelling - unless those exact same actions are actually (YAGNI) used as endpoints of a web service. render :partial => '..' is such an sweet, simple and natural paradigm to web programming.

In my head it's much easier to imagine manipulating a UI based on objects and their state, rather than partial snippets of HTML. It seems like it would get complicated to track the pieces of html you needed to request in order to redraw only portions of the UI. Wouldn't there still be a lot of javascript involved with that logic?

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

#23

Post by ayanb »

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 does this impact if you are aiming to build a JSON API too?

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

#24

Post by jashkenas »

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

I think that the truth of this is already admitted in that the really fancy bits of UI are being implemented in JS: http://37signals.com/svn/posts/3094-code-statistics-for-base...

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

#25

Post by rgoddard »

dos1 wrote: post #21
latch wrote: post #19

I have to say, reading this made my day. I've been feeling such a push towards client-side templates lately, that I felt like it was just me that didn't get it. I really don't understand what's so compelling - unless those exact same actions are actually (YAGNI) used as endpoints of a web service. render :partial => '..' is such an sweet, simple and natural paradigm to web programming.

In my head it's much easier to imagine manipulating a UI based on objects and their state, rather than partial snippets of HTML. It seems like it would get complicated to track the pieces of html you needed to request in order to redraw only portions of the UI. Wouldn't there still be a lot of javascript involved with that logic?

Normally that basic cycle would go: 1. I need to view some data, if I do not already have it, request it. 2. Generate html from data 3. Take generated html and place in appropriate place on page.

This skips step 2 by requesting the required html rather then the raw data. Step 2 is the part that would require the most code.

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

#26

Post by robinduckett »

Aren't they are using a lot of client side UI code in order to replace parts of the UI with updated HTML from the server?

They have caching on the server side but that can only account for some of this.

Although in my couple of years of using Basecamp in my previous job, I never found it particularly "snappy" but then I was one user out of a team of five, out of how ever many users they have.

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

#27

Post by zaidf »

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…

I have to agree here. A major problem with client-side json is the need for additional documentation and likelihood of things breaking because of simple html edits.

For example, if you are populating a bunch of divs inside a parent div with the data returned using json, you would describe this using something like jquery selectors. Now if someone else comes and moves around the div during a redesign, he must go through whole bunch of js to make sure his shuffling of the divs around won't break the jquery selectors populating the data from json.

Now think about having a parent div that is simply populated with returned HTML from server-side and it seems way easier than using json to populate the data.

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

#28

Post by roc »

latch wrote: post #19

I have to say, reading this made my day. I've been feeling such a push towards client-side templates lately, that I felt like it was just me that didn't get it. I really don't understand what's so compelling - unless those exact same actions are actually (YAGNI) used as endpoints of a web service. render :partial => '..' is such an sweet, simple and natural paradigm to web programming.

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

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

#29

Post by latch »

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 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 super dumb, but to me this approach is going to result in faster rendering.

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

#30

Post by rkalla »

Are you guys taking care to send as-plain-as-possible markup from the server to the client and then style it up to keep most the UI development in CSS or are you just sending through raw, styled HTML that gets inserted as-sent directly into the page?

This reminds me of the early days of Java Servlets when people would stream back HTML from inside their Java Servlet code to JSP pages to build it out... made it impossibly hard to edit the templates.

Then the Java world moved to templating engines, but it was still the same idea.

Just curious how you are managing this pain point (I am not a Ruby dev so maybe there is a well-known 'best practice' templating approach?).

Post reply on HN