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

#41

Post by jondot » Fri, Feb 17, 2012, 4:26 PM UTC

boucher wrote: post #37

jondot wrote: post #33

Earlier quoted context omitted.

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.

I agree that you do most of these arguments when most of your content render on the servers too. However, you DO have limited resources (time, money, people), and these points become more and more painful as you push towards client side.

Still, I insist that some of these arguments are client side specific. Once instance is javascript template rendering speed. Another is, that you would prefer getting statistics on your speed of rendering at the server's side where it is easily controllable and deterministic, rather than shuffle around to close that loop and build a usage service to report back usage and statistics to from the client's side.

I give my arguments from pain and experience in both sides, and I still do both sides despite of the arguments (since it is not always my own choice).

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

#42

Post by joshontheweb » Fri, Feb 17, 2012, 4:29 PM UTC

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.

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

#43

Post by jonknee » Fri, Feb 17, 2012, 4:31 PM UTC

zaidf wrote: post #27

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…

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

That's nonsense, the same issue would apply on the server side templates. If you go around messing with DIVs without an idea of the consequences, you will get in trouble regardless of your templates being on the server or client. If you try to have the designer do a redesign without testing the application afterwards, you're always in for trouble.

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

#44

Post by dhh » Fri, Feb 17, 2012, 4:35 PM UTC

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 whatever they're peddling. Meh.

Yes, it's great to occasional dip into advanced client-side when that's needed. Just like Flash had its legitimate use cases here and there. But for the bulk of the UI interactions we're giving people, it's just not needed (or desired).

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

#45

Post by abdelm » Fri, Feb 17, 2012, 4:39 PM UTC

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

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

#46

Post by VMG » Fri, Feb 17, 2012, 4:43 PM UTC

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…

A small change in state can cause a large change in the view.

When the server renders the html, it has to send all the portions of the view that have changed. When rendering client-side, the server only needs to send the portion of the state that changed.

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

#47

Post by nathansobo » Fri, Feb 17, 2012, 4:48 PM UTC

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…

Agreed. I prefer writing UI code on the client. But you need quality abstractions because it is more complex than doing everything on the server where all your data is at arm's length. I've written two frameworks that make it easier... SpacePen for the view (https://github.com/nathansobo/space-pen) and Monarch for the model: (https://github.com/nathansobo/monarch-rewrite)

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

#48

Post by ColinCampbell » Fri, Feb 17, 2012, 4:50 PM UTC

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…

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: everything on mobile, desktop clients not close to a server), needing to go back to the server to render will ruin the perceived performance of your app. Well-written applications running on the client can take a change and optimistically render that before the change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.

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

#49

Post by jarrett » Fri, Feb 17, 2012, 4:52 PM UTC

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…

Very true. This is why I'm sticking with a server-heavy design (i.e. Rails) for my main projects. I agree with all of your arguments about the difficulties of testing. And I'd add that there's a distinct lack of tools for testing client-side. Sure, you can get unit tests for client-side JS, and you can run integration tests in Selenium etc.. But the client-side testing ecosystem is tiny and immature compared to that for server-side testing. This will all change, but for now, I don't envy anyone who has to test a heavily client-side app.

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

#50

Post by latch » Fri, Feb 17, 2012, 4:56 PM UTC

VMG wrote: post #46

latch wrote: post #29

Earlier quoted context omitted.

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…

A small change in state can cause a large change in the view. When the server renders the html, it has to send all the portions of the view that have changed. When rendering client-side, the server only needs to send the portion of the state that changed.

Good point, thanks. So it potentially provides you with opportunities for further optimization. I guess the message from DHH is that they hit their performance targets, so this would be an unnecessary optimization (and I'm tempte to say "non-trivial to implement"..but now I know I'm being biased..)