> 1. Should I do it on the client or the server?

I think most applications use both client and server components. If your question is more on the lines of which one plays a major role, it depends mostly on the app. GMail won't be half as good without all the JS magic, but again, I assume it also has a heavy server component.

> 2. What should be travelling between the client and the server?

If you need any client side processing or are using a framework which works on raw data(backbone.js), then json/xml/...; or else if your goal is to run the app without reloading unnecessary parts, html is a better idea.

> 3. Based on the answer to #2, what else do I need on the client?

I am not sure what you are looking for here, but if your goal is to make a responsive app, there are some basic things to take care of.

Have bookmarkable links and don't break the back button. Doing that is breaking the base paradigm, and plain ajax does that.

Use something that provides bookmarkable links, and doesn't break the back/forwrad button; and at the same time, doesn't reload the whole page when only a small portion of the page needs reloading.

pjax is one such solution - the 37signals guys investigated it, then went with their home grown solution, but I think pjax will work just fine for majority of use cases.

The trick to pjax is serving content without layout if it is a pjax reques; with layout otherwise. There is nothing you can't handroll, but 1) why would you want to? 2) pjax uses pushState to preserve links and back button behavior.

Here is the pjax code:

https://github.com/defunkt/jquery-pjax

And here is a gist in Flask/Python which shows conditionally including the layout:

https://gist.github.com/830fc28c680e77759b4b

More important than whether to send html, json or xml is WHEN to send that content. People underestimate just how painful latency is to the user because they're sitting right next to their web server. Digg takes 15 times longer to load from bangalore than from california (see http://www.slideshare.net/kkjjkevin03/geographic-distributio... ). The thing that client-side rendering allows is caching your application UI in the browser and on the CDN. The server only gets contacted when it's absolutely necessary.

If you go mobile, it gets worse, because sometimes you'll lose the network for a few minutes, or even a few hours. Building a web app that keeps running in that scenario is possible, but only by embracing a client-side philosophy. In my personal opinion, mobile is going to be the dominant way that people connect, and the network is not going to be robust enough to render mobile web apps on the server.

Thanks you for the links. I found a simple Rails pjax app and I am going through the code right now: https://github.com/edison/pjax-rails-sample

Looking at the rails pjax_rails gem https://github.com/rails/pjax_rails I see it automatically patches layout to return false when the request is pjax.

https://github.com/rails/pjax_rails/blob/master/lib/pjax.rb#...

    layout ->(c) { pjax_request? ? false : 'application' }

So in the sample app you pointed out:

    def show
      @post = Post.find(params[:id])

      if pjax_request?
        render layout: false
      else
        respond_to :html
      end
    end

is the same as:

    def show
      @post = Post.find(params[:id])
    end

Also, pjax-rails converts the following selection to pjax:

https://github.com/rails/pjax_rails/blob/master/lib/assets/j...

    $('a:not([data-remote]):not([data-behavior]):not([data-skip-pjax])')

I was a bit baffled by the example app since it didn't appear to be doing any pjaxy stuff, but rails being opinionated, I see all links are pjax(except the not classes show above), and layout is turned off for pjax requests.

I put some debug printouts in his example notes controller and it seemed to be setting the no layout rendering option correctly, but as you say, the checks in the controller may be redundent. Anyway, I am planning on giving pjax a very good look: I find doing a lot of client side coding to be tedious and is something to be minimized.

Nice screencast too:

http://railscasts.com/episodes/294-playing-with-pjax

+1, I'm also none the wiser having read the OP and the comments here.

I'm quite used to a fully server side model so I'm currently experimenting with a few side projects to see just how much I can put into the client without going anywhere near the server.

I think once I've pushed it to its limits I can start working my way back to the server and achieve a good balance. None of this would of course be bearable without coffeescript and a nice js framework like backbone.