
Rendr - Use Backbone on both the server and client - jlogsdon
https://github.com/airbnb/rendr
======
bryanlarsen
My brother released a very similar project about 8 months ago.[1] He never did
properly announce or document it so it's no surprise that nobody else is using
it.

Of course, it's not like rendr has any real documentation, either.

However it has been working very well for us, so it is validation of the rendr
approach.

A quick glance at their documentation indicates a very similar design,
comparing the two projects should be instructive.

1: <https://github.com/wvl/highbrow>

~~~
bryanlarsen
I looked a little bit more at the rendr source, and one thing that immediately
jumps out at me is the code BaseView#getTemplateData[1] which very tightly
couples the model & views together. You should totally steal highbrow's
ViewModel code, which is very sweet. (But you might want to come up with a
better name). Rather than passing @model.toJSON() as template data, highbrow
creates a ViewModel from the model or collection or out of thin air, and
passes that in as template data.

Here's a typical ViewModel definition (in JS):

    
    
        foo.vm.Resource = highbrow.ViewModel.extend({
          lastUpdated: function() {
            return moment(this.model.get('modifiedAt')).fromNow();
          }
        });
        foo.vm.Resource.attrs(['name', 'content']);
    

This shows the main two features of ViewModel's: a whitelist of attrs that the
template can access directly, and a set of functions that would otherwise end
up polluting your model with view side code.

This decoupling dramatically improves the structure of our applications,
without introducing Rails style controllers which are also totally misnamed in
my opinion. Rails controllers are essentially two things: routers and MV-
shims. Splitting the two makes for much improved program structure.

1:
[https://github.com/airbnb/rendr/blob/master/shared/base/view...](https://github.com/airbnb/rendr/blob/master/shared/base/view.coffee#L54)

2: [https://github.com/wvl/highbrow/blob/master/src/view-
model.c...](https://github.com/wvl/highbrow/blob/master/src/view-model.coffee)

~~~
frontendbeauty
Cool, I like that ViewModel pattern. You could certainly use that with Rendr.

------
roskilli
More background and discussion about Rendr and how it fits into the stack of
the nodejs app AirBnB built: [http://nerds.airbnb.com/weve-launched-our-first-
nodejs-app-t...](http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-
to-product)

------
neebz
I have gone through the blog post and bit of code but I am a bit stomped. Can
anyone tell what is the flow here?

If I go directly to /search/q=hello, the request will go to server, it will
render the HTML on server and send it to client. What happens next? Do they
send all the Javascript + client-side templates alongside as well so that
further requests are catered on client?

Think I should fiddle around with the sample app.

~~~
napoleond
_Do they send all the Javascript + client-side templates alongside as well so
that further requests are catered on client?_

Yes.

------
hunvreus
We used a similar approach with Bones
(<https://github.com/developmentseed/bones>) for a while and ended up dropping
it for a more decoupled architecture (API on side and static client on the
other).

I remember chatting with Spike about this at a Backbone.js meetup at Airbnb's
office last year, I think they were aware of the limitations similar
frameworks were running into.

I'd be interested in seeing how this play outside of Airbnb's use case, but
from experience I think sharing backbone.js on both client and server, while
neat, end up being pretty constraining.

------
untog
This looks fantastic. Anyone know how well something like this deprecates? My
dream is to have a mobile site that is all Backbone-y on iPhone/Android but
falls back to server-based rendering when loaded through a Blackberry or
similar.

~~~
ajacksified
The goal is to render everything server-side; you'll need to handle POSTs and
whatnots separately (since rendr is effectively middleware, so you can do what
you like and redirect back to a GET route to display data.) In theory, it
deprecates perfectly.

------
peedro
We @sc5io decided to release our own research regarding this very same issue.

I love the Rendr approach, yet we feel that our backbone-serverside framework
provides an even more flexible way to tackle the same issue.

Read more at SC5 blog ([http://blog.sc5.fi/2013/04/serving-backbone-for-
robots-legac...](http://blog.sc5.fi/2013/04/serving-backbone-for-robots-
legacy-browsers/)) or at the Mozilla Hacks article:
[https://hacks.mozilla.org/2013/04/serving-backbone-for-
robot...](https://hacks.mozilla.org/2013/04/serving-backbone-for-robots-
legacy-browsers/)

------
redeemedfadi
I'm using <http://phantomjs.org/> to render my EmberJS app's pages and serve
those to crawlers. I hope to write a blog post about it soon. It has the
benefit of working with any software stack, not just Node.js.

Rendr looks like a much more robust solution, however. I'll have to see if I
can incorporate some of it's techniques, specifically serving HTML on page
load.

~~~
muloka
Cool I'd be interested in reading about that.

------
xiaoma
This is pretty cool. I've been playing around with a variety of JS frameworks
recently and code sharing is probably my 2nd favorite thing about meteor.
Anybody know if these guys are hiring? My school's big interview day is on
Thursday and airbnb's front-end stack looks appealing.

~~~
frontendbeauty
We are absolutely hiring! airbnb.com/jobs

------
LAMike
I remember reading their blog post about their "Holy Grail" framework, but I
couldn't really understand what made it so cool. Can someone explain to a noob
like me why someone would consider Rendr the Holy Grail of frameworks?

~~~
tengkahwee
MVC is being used for web development. The M part, model, handles the rules
for inputs. This would trigger validation errors. In a typical stack, we code
the server-side model in, say, Ruby on Rails, and duplicate the same model in
client-side model in JavaScript so it can detect things like minimum password
lengths without sending data back to the server. The holy grail is to have
both server-side and client-side in JavaScript and also sharing the models as
well, with that we reduce amount of things we have to code.

~~~
bryanlarsen
This approach doesn't help. With highbrow and presumably rendr, you still have
'client side' & 'server side' components to your project. The 'server side' is
typically just a JSON REST API. In our case, it uses mongoose to talk to
mongodb. The 'client side' talks to the API and renders HTML; on first load it
actually runs on the server. The client side uses Backbone.js models.

So you still need both backbone & mongoose/whatever validations if you want
them both on the client & server side. In practice, the system is fast enough
that server side validations may be sufficient.

------
seivan
Wow, their samples sure look like Batman.js. Also, I'm a fan of them for going
with CoffeeScript, they have taste.

But seriously, looks very much like Shopify's batman.js <http://batmanjs.org>

~~~
bryanlarsen
They're both written in coffeescript, and they're both written about the same
time so have very similar influences.

I think most of the similarities you see stem from those two points.

But there are some massive differences:

\- batman.js is Rails-style MVC, rendr is based on Backbone so you must supply
your own controllers. A good argument can be made that Rails is not truely
MVC, but it at least attempts to do so. rendr is MV.

\- RENDR runs and renders on the server. batman.js relies on a Rails or REST
app on the server.

\- rendr is based on Backbone.js and Express, batman.js isn't

~~~
seivan
I wasn't pointing out on those portions, I was merely just reflecting over the
API design :) keywords and etc

------
cjbarber
This is really fantastic - thanks to Spike and the rest of the Airbnb guys for
releasing it to the world.

My interpretation of the key benefits: large speed increases for users, and
vastly improved SEO.

------
trungonnews
I've been waiting for YUI team to fit the YUI App Framework(the equivalent of
BackBone) into Mojito. But seems like you've beaten them to it. :)

Great job!

------
Axsuul
The Holy Grail!

------
ymn_ayk
I don't like the idea of rendering client code in the server.

~~~
trungonnews
Don't think of it as client or server code. Think of it as presentation code.
And it happens to run on both the server and browser.

Though, don't write your business code in javascript. Hell to maintain.

------
apunic
> Library, not a framework

> Talk to RESTful API

> Simple Express middleware

Hard times for Meteor

