

MVC with CoffeeScript - andrzejkrzywda
http://andrzejonsoftware.blogspot.com/2011/09/3-steps-to-mvc-in-javascript.html

======
lucaspiller
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?

~~~
jashkenas

        > 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>

------
igorgue
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)

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

~~~
wavephorm
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.

~~~
exogen
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.

