Maybe I'm just doing it wrong but when I've used Backbone I have found myself using the View to do most of the controller work, and having this just render a JST template. The problem is that my page is more split up than in a typical Rails MVC app.

As an example (following the game analogy), I have a column on the left displaying player stats, and the main game board on the right. The left column lets you do things such as editing a players details and inviting friends, and the game board lets you play the actual game. In Backbone I would have a View for the player column and a View for the game board, which themselves trigger other Views, as the 'controller' in Backbone doesn't really seem a logical fit for this. I'm guessing this is why they have now renamed it to Router.

I must be doing it wrong... are there any good examples of complicated apps built in Backbone?

    > Maybe I'm just doing it wrong [...]

If it's working well for you, you're probably doing it right: http://documentcloud.github.com/backbone/#FAQ-tim-toady

    > are there any good examples of complicated apps built in Backbone?

Tons. Scroll down: http://documentcloud.github.com/backbone/#examples

I'd do:

    class Player extends Backbone.Events

And that would deal with this part:

    class Player
      constructor: (attributes) ->
        _.extend(this, Backbone.Events)
        _.extend(this, attributes)

I wouldn't tag CoffeeScript as 'make your code prettier', it brings so much more.

Although I agree, I'd like to see you back that up. What (for you) makes it more than syntactic sugar?

I was recently at a sproutcore meetup where Yehuda Katz presented and mentioned one of the reasons he suggests using Coffeescript is because it can (as in now or in the future) generate more efficient javascript code than the typical javascript developer will write.

Like what?

From what I've seen it brings an alternative syntax without reducing any complexity. And before you say it, no, removing braces does not reduce complexity.

It reduces complexity by making semantics that many programmers expect a part of the syntax. For instance, methods always being bound to their instance (=>). To use one striking example, it turns this:

    class Widget
      render: =>
        alert "Here I am!"

    class Button extends Widget

...into this equivalent JavaScript:

    var Button, Widget;
    var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; }, __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
      for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }
      function ctor() { this.constructor = child; }
      ctor.prototype = parent.prototype;
      child.prototype = new ctor;
      child.__super__ = parent.prototype;
      return child;
    };
    Widget = (function() {
      function Widget() {
        this.render = __bind(this.render, this);
      }
      Widget.prototype.render = function() {
        return alert("Here I am!");
      };
      return Widget;
    })();
    Button = (function() {
      __extends(Button, Widget);
      function Button() {
        Button.__super__.constructor.apply(this, arguments);
      }
      return Button;
    })();

I'd say that's more than sugar. That is complexity reduction.

well, you definitly didn't use it.