User interface thinking in Rails

I posted a short tip the other day in which I suggested a couple tools for building client-side code on top of a Rails app. I didn't go into much detail on this tip, so today I want to explain a little more about the problem I'm trying to solve. This might help anyone who didn't quite understand the last tip better see where I'm coming from.

Over the past six months or so I've worked on a few apps using Ember.js. I'm currently using it at our largest client and at the same time I'm coaching their developers on building apps with Ember. What I've learned during this time is that teaching Ember is not so much about teaching a framework, but about trying to shift developers' thinking about the responsibilities of MVC in a client-side app away from server-side thinking.

Imagine any iPad app. You don't usually have a single screen that just reloads every time you want new information. Instead, you have a navigation list that pops up when you tap a button, or a detail view that gets filled with content when you choose a new item. You are rarely changing the contents of the screen entirely, but more often bringing components in and taking components out.

This is no different with rich web applications. Your core unit has changed from being a "page" that gets rendered each time the user clicks a link or button, to a component that is rendered in response to an event and added to (or removed from) the page.

However, when building web apps in Rails it's not always easiest to start out that way. Instead, I've found it much easier to build an app without any rich interaction at all. That's right: 0 lines of Javascript code. This allows me to focus on making core parts of the app stable and fast: the data model, data loading and getting a decent UI in place. I can build this type of interaction very quickly to get something in front of the client, get their feedback and then iterate on it. When I am ready to start adding some rich interactions on top of that, how can I start to shift my architecture towards this new way of thinking interactively?

This is where I need to change my approach to server-side MVC a little bit. The traditional Rails app has a single controller that loads all the data for a page and then renders a template and layout for the entire page. Responding to user interaction triggers another controller to load data for the next page and render it.

Client-side MVC frameworks like Ember.js change this model, such that each component on a page has its own controller and can respond to its own events. It's a very clean encapsulation of logic that makes for greater reusability and modularity. You know, the stuff of good code.

But that's a client-side framework, and we've already done all the work our app needs on the server-side. Surely we don't want to rewrite all that logic on the client. How can we get a similar approach to what Ember.js does but in Rails?

I'll post another tip soon showing examples of how I've done this. Hopefully now, though, you can more clearly see the problem we're facing as developers of traditional server-side apps. I'm curious to know how others have solved this problem. Please feel free to comment on this problem and how you have solved it for yourself.