Their framework is intended solely for coffeescript devs. Here's their example in javascript:

  (function() {
  var Shopify;
  var __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;
  };
  Shopify = (function() {
    function Shopify() {
      Shopify.__super__.constructor.apply(this, arguments);
    }
    __extends(Shopify, Batman.App);
    Shopify.root('products#index');
    Shopify.resources('products');
    return Shopify;
  })();
  Shopify.Product = (function() {
    function Product() {
      Product.__super__.constructor.apply(this, arguments);
    }
    __extends(Product, Batman.Model);
    Product.persist(Batman.RestStorage);
    return Product;
  })();
  Shopify.ProductsController = (function() {
    function ProductsController() {
      ProductsController.__super__.constructor.apply(this, arguments);
    }
    __extends(ProductsController, Batman.Model);
    ProductsController.prototype.index = function() {
      return this.redirect({
        action: 'show',
        id: 1
      });
    };
    ProductsController.prototype.show = function(params) {
      return this.product = Shopify.Product.find(params.id);
    };
    return ProductsController;
  })();

}).call(this);

To be fair, that's the compiled CoffeeScript. While it certainly is still fairly readable (even writable), the JavaScript you write by hand won't have the same "compiled feel".

This is more like what you would write by hand for the above code if the core constructors had a Backbone-style .extend function [1], which it likely would have if normal JavaScript usage was considered for the initial release (which I recognise is what this is - you can't expect everything first time):

    var Shopify = Batman.App.extend()
    Shopify.root('products#index')
    Shopify.resources('products')

    Shopify.Product = Batman.Model.extend()
    Shopify.Product.persist(Batman.RestStorage)

    // I'm never sure about how much I'm expected to mimic CoffeeScript code
    // when using libraries written in CoffeeScript and the source code is
    // written in a language I'm not practiced at reading - I've been bitten in
    // the past by CoffeeScript-only examples which *assume* you're transpiling
    // to JS in your head to insert the implicit return of the result of the
    // last expression.
    Shopify.ProductsController = Batman.Controller.extend({
      index: function() {
        return this.redirect({action: 'show', id: 1})
      }

    , show: function(params) {
        return this.product = Shopify.Product.find(params.id)
      }
    })

If there's common boilerplate associated with each constructor, you could also go further and customise the extend method for each one to take care of it if provided with certain configuration details, e.g.:

    var Shopify = Batman.App.extend({
      root: 'products#index'
    , resources: 'products'
    })

It always puzzles me that people look at some of the implementation details CoffeeScript shields programmers from and throw their hands up in the air and admit defeat [2] when we have a language as flexible as JavaScript at our disposal to hide some of the uglier implementation details in APIs we define.

[1] https://github.com/documentcloud/backbone/blob/master/backbo...

[2] http://news.ycombinator.com/item?id=2923694

It's readable, but any framework that requires you to recreate inheritance yourself is going to have a hard time selling to a js audience when Backbone works perfectly well (and can be written in cs just as easily).

>Their framework is intended solely for coffeescript devs

Would makes sense to say this on the front page of the project. Most Coffeescript projects do.

I'm not trying to be obnoxious or anything but doesn't this just show how much cleaner CoffeeScript is compared to js?