Bridging the client-side/server-side divide

Traditionally, web apps have fallen into one of two buckets: mostly server-side, or mostly client-side. Splitting the difference in a single application has been complicated by issues of code duplication and getting the right data back and forth.

Recently, Node.js has made the split approach easier by allowing the same code to be shared between the client and server. But what if you have an existing Ruby or Python server-side web app, and you’d like to move portions of the overall app to a client-side approach?

That’s the situation we found ourselves in recently at Typekit while building our new font browsing UI. We knew we wanted a fast, fun, app-like experience, and realized that it would require a mostly client-side approach. On the other hand, it also had to blend seamlessly with our existing server-side Ruby application.

In this talk, instead of focusing on the specific technologies that we used to accomplish our goals (like Knockout.js in the client and Johnson on the server), I’ll take a more technology-agnostic look at the patterns that allowed us to succeed:

• How declarative bindings enabled us to simplify our JS code and deal with app-level concepts instead of brittle DOM details.
• How the MVVM (model – view – view model) pattern helped us separate concerns between the client and server: models in Ruby, templates in pure HTML, view models in JavaScript, with adapters to move data back and forth as JSON.
• How we got client and server-side template rendering by using the same data that we send to the client to evaluate declarative bindings on the server instead (using a JavaScript interpreter).