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

31–40 of 135 posts

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

#31

Post by dos1 »

rgoddard wrote: post #25
dos1 wrote: post #21

Earlier quoted context omitted.

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.

I disagree. I work on an app that is entirely client side rendered. We use the JSON data approach. Step 2 is trivial. There are many JS templating engines out there. It takes almost no code. The part that's hard is step 1, figuring out if you have the right data or whether your data is stale. And then, to figure out which part of the UI needs to be redrawn. This is where frameworks like Backbone can come in handy.

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

#32

Post by hello_moto »

I find GWT to be the best platform to do full-blown fat client-side paradigm due to several reasons:

1) UI Templating (like XAML)

2) MVP Pattern + JUnit = test automation as part of your build with minimum investment to infrastructure (most JS based solution requires investment on infrastructure)

3) Resource Bundle (similar to Asset Pipelining) cut down HTTP requests

4) Resource splitting (follow up from #3) to reduce the size of the responses when it comes to resources

5) JS binding (like C binding, C++ binding, JNI, etc) to support popular JS library

6) Top Notch Compiler (arguable... but it's there) that can also prune dead code

7) JS switching based on browser's request (IE browser will get IE-specific JS)

8) CSS variable substitution (like Sass)

9) History framework.

10) Flexibility: end point can either return JSON, XML, or use the built-in XML-RPC mechanism (Java only).

The disadvantages are: it's Java and requires compilation.

I like GWT the most so far because I don't have to find libraries or tools that support all of the above (Sass, mustache, various js unit-testing tools, library to merge and compile css/js, etc).

YMMV.

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

#33

Post by jondot »

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…

With all of the backbone and node.js hype going around, people tend to forget that client-side development is developing on the client's side. Sooner than later you will have to deal with

* nondeterministic testing,

* interactive testing (leaving machines on to run interactive testing at night),

* most of the bugs will live on the client side,

* you'll have to support each and every machine's quirks (you can't pretend everyone are on at least core i5 and chrome, people WILL have machines that do javascript client side template rendering SLOWLY).

* you'll have to find ways to diagnose problems at the client's site, and you will maintain a fleet of various computer configurations to run sanity on.

* which will also cause you to start investing in pairwise testing

* i can go on

DHH is COMPLETELY right. Just because the universe is not ready enough for client side "SPA"s (universe=browsers,internet)

I'm laying my arguments out of experience - I've been a long time Ruby/Rails/.Net/JVM server side dev as well as enterprise software dev (enterprise desktop/workstation application suites, as complex as visual studio and the sorts). I have several node.js projects in production and I'm also doing a couple of projects with Backbone.

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

#34

Post by dhh »

rkalla wrote: post #30

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

I'm not sure I understand the pain point you're describing. What's "styled HTML"? We're sending HTML across the wire that looks exactly like the HTML we used to render the initial page. It has classes, ids, and custom data descriptors.

We have not experienced any pain doing this.

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

#35

Post by boucher »

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…

Word. Seems like they are going out of their way to avoid doing client side work even when it would be far easier to do so. Also seems motivated by the desire to keep Rails relevant, but without actually trying to evolve Rails towards being more useful for client side driven apps.

On the flip side, you have to congratulate them on what seems like really great results. I'm definitely in favor of doing what works and what you're comfortable with. I just don't think Basecamp Next Next will be written this way.

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

#36

Post by latch »

roc wrote: post #28
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 .

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.

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

#37

Post by boucher »

jondot wrote: post #33
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…

With all of the backbone and node.js hype going around, people tend to forget that client-side development is developing on the client's side. Sooner than later you will have to deal with * nondeterministic testing, * interactive testing (leaving machines on to run interactive testing at night), * most of the bugs will live on the client side, * you'll have to support each and every machine's quirks (you can't preten…

Your arguments are a checklist of responsibilities for anyone running any web software, whether the actual DOM elements are being rendered on the server or the client.

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

#38

Post by MatthewPhillips »

latch wrote: post #29
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 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.

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

#39

Post by MatthewPhillips »

ayanb wrote: post #23
dhh wrote: post #5

Earlier quoted context omitted.

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?

Double work.

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

#40

Post by rkalla »

dhh wrote: post #34
rkalla wrote: post #30

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

I'm not sure I understand the pain point you're describing. What's "styled HTML"? We're sending HTML across the wire that looks exactly like the HTML we used to render the initial page. It has classes, ids, and custom data descriptors. We have not experienced any pain doing this.

You answered my poorly-worded question. Thanks.
Post reply on HN