July 2nd, 2013 Spike Brehm from Airbnb shares Rendr wtih Cleanweb

http://www.meetup.com/Cleanweb-NYC/events/121027282/

On July 2, the Cleanweb group in NYU-Poly in DUMBO, Brooklyn hosted a special talk with Spike Brehm, front-end engineer of Airbnb who flew in from San Francisco. The topic was Airbnb’s passion project—an open-source project called Rendr that thinks will help make for a better web experience.
 
https://www.airbnb.com/
 
 
Presented by Brehm four months ago in the West Coast, Rendr now has some curious developers testing its library of running Backbone.js apps on both the client and the server sides.
 
https://github.com/airbnb/rendr
 
What is Rendr? Under the hood, it is JavaScript MVC on client & server; Backbone & Handlebars, Base View, Base Model, Base Collection, Base App,Client Router, ServerRouter with a set of Express middleware. What’s good about it, Brehm said, is that it has minimal glue between client and server.
 
Imagine a better Javascript, a better SEO, a better, faster web experience adapted by everyone from a company known more for worldwide accommodations. Initially, the focus was on improving SEO (search engine optimization), but it turns out that a new way of building web applications is much more interesting for them—and hopefully, the outcome is good for all. 
 
Brehm clarifies that the intention is not to replace Rails, Meteor, Ember or Backbone, but to explore the problem of isomorphic Javascript applications and stimulate discussion in the community. 
 
Here is Brehm’s simple set of design goals guiding Rendr’s development:
 
Write application logic agnostic to environment. Indicating what data to fetch, which template to render, which route to match, how to transform a model’s data — this logic can and should be abstracted from specific implementation details as much as possible.
 
Library, not a framework. In true Backbone style, Rendr strives to be a library as opposed to a framework. A small collection of base classes which can be built upon is easier to adopt and maintain than a batteries-included web framework. Solve the problem at hand without imposing unneeded structure on the application.
 
Minimize code like if (server) {…} else {…}.
 
If your application has a bunch of conditions that look like this, then it means you’re doing something wrong. It’s a sign of a leaky abstraction. Of course, sometimes it’s necessary to know which environment you’re in, but that logic should be consolidated and abstracted away as much as possible. Which leads us to:
 
Hide complexity in the library. There are a few really tricky problems that need to be tackled to achieve these other goals. The complexity of the solutions should be hidden in the library, keeping the application code clean, but remain accessible when it’s time to override core behaviors.
 
Talk to a RESTful API. Backbone is great at integrating with a RESTful API. Let’s follow that convention, keeping the data source separate from Rendr itself. It should be possible to write adapters for different data sources, such as Mongo, CouchDB, Postgres, or Riak, but the library shouldn’t impose structure on your model layer.
 
No server-side DOM. We prefer string-based templating over using a DOM on the server because DOM implementations are slow, and, well, because it feels hacky. You shouldn’t need a DOM to render HTML. However, I’m curious how this will change though once WebComponents become commonplace.
 
Simple Express middleware. Express is the de facto Node.js web server. Rendr should fit with Express convention, exposing a few simple middleware. A nice effect of this is that you can tack on Rendr routes onto any existing Express app, or have Rendr and non-Rendr content served from the same codebase as necessary.
 
With Rendr, it is hoped that developers could just concentrate on writing application code and the app could serve up genuine HTML on first pageload, resulting in an improved SEO.