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

This is all fascinating ... but does it feel like a sustainable approach going forward, or more like a turbo-charged horse and buggy?<p>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?<p>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).<p>I think that the truth of this is already admitted in that the really fancy bits of UI are being implemented in JS: <a href="http://37signals.com/svn/posts/3094-code-statistics-for-basecamp-next" rel="nofollow">http://37signals.com/svn/posts/3094-code-statistics-for-base...</a>

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:<p><pre><code> 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? </code></pre> Even though I've read all your great discussion points, I'm not sure I'm that much smarter. But it's nice to know I don't suffer alone. :-)

Hmm, degraded development experience of doing everything on the client?<p>Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem.<p>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 simple HTML, so it's arguably a worse user experience due to the lag.

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 =&#62; '..' is such an sweet, simple and natural paradigm to web programming.

Cross posted from a comment by DHH on this post<p>&#62;&#62; We use nodejs for local development via Sam’s Pow server, but there’s no nodejs in Basecamp Next itself. It’s all Ruby on Rails. We’re running the default stack using Rails 3.2+, MySQL 5.5, Memcached, a tad of Redis (mostly for Resque), ERB , test/unit, CoffeeScript, Sass, and whatever else is in the default box you get with Rails.

Awesome, very interesting article that shows you don't always have to go full client side to get a snappy app.<p>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).<p>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?

I find GWT to be the best platform to do full-blown fat client-side paradigm due to several reasons:<p>1) UI Templating (like XAML)<p>2) MVP Pattern + JUnit = test automation as part of your build with minimum investment to infrastructure (most JS based solution requires investment on infrastructure)<p>3) Resource Bundle (similar to Asset Pipelining) cut down HTTP requests<p>4) Resource splitting (follow up from #3) to reduce the size of the responses when it comes to resources<p>5) JS binding (like C binding, C++ binding, JNI, etc) to support popular JS library<p>6) Top Notch Compiler (arguable... but it's there) that can also prune dead code<p>7) JS switching based on browser's request (IE browser will get IE-specific JS)<p>8) CSS variable substitution (like Sass)<p>9) History framework.<p>10) Flexibility: end point can either return JSON, XML, or use the built-in XML-RPC mechanism (Java only).<p>The disadvantages are: it's Java and requires compilation.<p>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).<p>YMMV.

I think in the whole client-side rendering debate, a lot of people miss the fact that there is a one-to-one correspondence between JSON and a certain subset of HTML, that can be illustrated by the following example:<p><pre><code> {"user": {"first_name": "David", "last_name": "Hansson"}} &#60;div class="user"&#62; &#60;div class="first_name"&#62;David&#60;/div&#62; &#60;div class="last_name"&#62;Hansson&#60;/div&#62; &#60;/div&#62; </code></pre> If, as 37signals basically seem to be doing, you restrict yourself to this subset of HTML and use CSS to do _all_ presentational styling, then honestly it’s all the same either way.

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?<p>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.<p>Then the Java world moved to templating engines, but it was still the same idea.<p>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?).

Interesting. We've just had a discussion in our team about moving as much as possible to the client becasue... developers enjoy writing CoffeeScript!

Is this similar to Quora's livenode/webnode2 (<a href="http://www.quora.com/Quora-Infrastructure/What-is-Webnode2" rel="nofollow">http://www.quora.com/Quora-Infrastructure/What-is-Webnode2</a>, <a href="http://www.quora.com/Quora-Infrastructure/What-limitations-has-Quora-encountered-due-to-Webnode2-LiveNode" rel="nofollow">http://www.quora.com/Quora-Infrastructure/What-limitations-h...</a>, <a href="http://www.bigfastblog.com/quoras-technology-examined" rel="nofollow">http://www.bigfastblog.com/quoras-technology-examined</a>, <a href="http://www.quora.com/Quora-Infrastructure/How-does-LiveNode-work" rel="nofollow">http://www.quora.com/Quora-Infrastructure/How-does-LiveNode-...</a>)?

I don't think push state is supported in IE (except ie 10):<p><a href="http://caniuse.com/#search=pushstate" rel="nofollow">http://caniuse.com/#search=pushstate</a><p>This makes it a non-starter for me.

Aren't they are using a <i></i>lot<i></i> of client side UI code in order to replace parts of the UI with updated HTML from the server?<p>They have caching on the server side but that can only account for some of this.<p>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.

I can't help but feel that you are sacrificing the flexibility of your UI in order to stay in your 'safe place'. IMO its easier to implement complex UI if you can deal with it all in the front end. I have used a similar approach before and felt like my hands were tied many times by it.

This ia a bit of a tangent, but Stacker feels like breadcrumbs that require more real estate than necessary. Maybe the physical metaphor is important, but my first thought was 'this is just bread crumbs'.

This is very similar to what Google+ does with Closure Templates.

I'm showing my ignorance of rails here, but is it hard to do the 'russian doll' style of fragment caching that DHH describes? Are there any gems that do this?

I just realized how "next last year" is an oxymoron... Or is it? A reference to the present per chance?

Is Stacker a proprietary 37 Signals thing? It doesn't seem to pop up after several search attempts.

&#62; Alexander, I think the Law of Demeter is shit and never follow it.<p>Classic DHH

What's the point of putting the tl;dr at the bottom?

advertising

Summary: Use window.pushState() to reduce HTTP requests and cache <i>every thing</i>.

or, you know, you can also stop using Rails.