Throne of JS: Eight JavaScript MV* Libraries Compared

It's similar to Knockout with data binding, dom templating, and some nice debugging tricks.

The entire thing clocks in around 900 lines with comments, and has no dependencies so if you're curious, have a look.

We had a few of the Enyo engineers up at Throne of JS, but we didn't get a speaking slot. Maybe next time.

I had no real requirements, except that I really preferred easily using CoffeeScript. Obviously all of them can be used with CoffeeScript, but some easier than others.

I embraced and evaluated Batman. This was before they updated their documentation a couple months ago. Their docs were so brief that I had to consult the (partially annotated) source for basic things like bindings, routings, etc.

I built a little example in about 5 days and called it quits. When it gets to 1.0 I'll take another look. Their new documentation looks promising.

I then went pursuing frameworks with automatic 2-way binding like Knockout (and batman). I really didn't want to go w/ Backbone because it doesn't provide that feature. But what I ended up finding is that implicit 2-way bindings like that are more of a performance blackbox. Not altogether bad, but that they have enough downside that they're not an absolute must-have.

I ended up choosing Backbone flavor Chaplin.

Chaplin is an opinionated implementation of Backbone written in CoffeeScript. It implements a Pub/Sub message bus using Backbone Events. It gives you defined structure that makes it easier to get started. And it provides garbage collection which can be super helpful. When a controller (and its models) is swapped out there are a lot of circular references that have to be manually broken for it to be garbage collected. Chaplin takes care of that for us.

And Brunch.io includes Chaplin now in its default recipe, which is also super helpful.

If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.)

The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app.

For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.