5 ms·

I'd like to see some examples in JavaScript, instead of CoffeeScript. Since at this point only a smaller subset of developers use CoffeeScript, I think it might

I'd like to see some examples in JavaScript, instead of CoffeeScript. Since at this point only a smaller subset of developers use CoffeeScript, I think it might be overall useful to more people if the provided examples used plain JavaScript (that, and CoffeeScript developers tend to understand JavaScript already, and may already be used to converting one to the other).

nciagra 15y ago
Sure, valid point. It's not something we work on day to day, so I don't have any readymade examples, but I'll definitely look into it. Thanks!
goodside 15y ago
The subtext is that you should learn CoffeeScript. It's an alternative syntax, not a new language. They wrote you a nice library and are giving it away under an MIT license. You don't get to pick the style they use to write the examples. That's like going to a science lecture and walking up to the speaker afterwards to say, "Hey, I think you have some great theories, but you really should lose that Australian accent of yours. Most scientists aren't from Australia, you know."
- mcantelon 15y ago
  >It's an alternative syntax Right... "alternative"... so makes sense to not give examples entirely in it unless your framework is intended solely for Coffeescript users.
  - deleted 15y ago
    [deleted]
  - MatthewPhillips 15y ago
    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);
    - nciagra 15y ago
      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".
      - MatthewPhillips 15y ago
        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).
      - insin 15y ago
        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/backbone.js#L1001-1010 https://github.com/documentcloud/backbone/blob/master/backbo... [2] http://news.ycombinator.com/item?id=2923694 http://news.ycombinator.com/item?id=2923694
- masterzora 15y ago
  They wrote you a nice library and are giving it away under an MIT license. You don't get to pick the style they use to write the examples. This is a response to something nobody's saying. Obviously if they write it they get to choose pretty much everything about it. Nobody is disputing such a thing. However, if one of the goals in releasing this is to be maximally useful, isn't the fact that raw Javascript is more readily understandable to more people a good thing to point out? Especially since it's highly likely that the team actually has the ability to do normal JS just as easily. If they disagree with such a goal, though, they can feel free to do whatever they want.
  - goodside 15y ago
    Nobody who knows CoffeeScript needs to be informed that JavaScript is more mainstream.
    - masterzora 15y ago
      Perhaps not, but that doesn't necessarily imply that the use of CoffeeScript-only examples was a calculated move to reach the audience they wanted instead of whatever came to mind first. It's worth at least reminding them that JS examples might be more useful to more people and letting them decide consciously whether they care.
      - MatthewPhillips 15y ago
        They use coffeescript's class inheritance. Here's the JS that compiles down to: http://jashkenas.github.com/coffee-script/#classes http://jashkenas.github.com/coffee-script/#classes If they showed JS examples it would instantly turn everyone off. Trust me, you do NOT want to use this with JS.
  - Cushman 15y ago
    This will be maximally useful if you learn CoffeeScript.
- learc83 15y ago
  I'd say it would be closer to the scientist giving the speech language in West Frisian to a group that's composed of 90% English speakers. Or maybe more accurately a speech in modern English to a group of early modern English speakers.
TrevorBurnham 15y ago
In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able. I think CoffeeScript is mainstream enough at this point that CoffeeScript-based documentation is a fine thing. Especially since, as they say at the top of the page, Batman.js "is written in CoffeeScript and its API is developed with CoffeeScript in mind."
- MatthewPhillips 15y ago
  > In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able. True, but that just basically means that using JS with Batman.js is going to be a pain. In backbone.js you also extend their base classes, but you do it in a js-friendly way (var Widget = Backbone.Model.extend). Not that there is anything wrong with a CS framework, but they should just say that it's a CS framework. The way CS compiles it's class inheritance to JS is not something I'd want to write raw.
  - jashkenas 15y ago
    For the record, the way that CoffeeScript does inheritance and the way that Backbone's "extend" does inheritance is almost literally exactly the same thing. Both simply create an empty object to serve as the prototype (calling new without actually running your constructor), set up the prototype chain correctly, and stash a reference so that calling `super` is easier later on. If "Child" and "Parent" are constructor functions (class objects), then the basic pattern is this: var ctor = function(){}; ctor.prototype = Parent.prototype; Child.prototype = new ctor; Child.prototype.constructor = Child; Fun.
    - MatthewPhillips 15y ago
      This is the way JS devs have been hacking inheritance for a long time. That's irrelevant though, we're not comparing CS to Backbone, we're comparing Batman.js to Backbone. Backbone handles the messy inheritance code for you. Batman.js relies on CS for that, but a JS dev is going to have to write the inheritance code by hand. I posted the JS equivalent of their example in this thread, it's nasty.

nciagra 15y ago

Sure, valid point. It's not something we work on day to day, so I don't have any readymade examples, but I'll definitely look into it. Thanks!

goodside 15y ago

The subtext is that you should learn CoffeeScript. It's an alternative syntax, not a new language. They wrote you a nice library and are giving it away under an MIT license. You don't get to pick the style they use to write the examples. That's like going to a science lecture and walking up to the speaker afterwards to say, "Hey, I think you have some great theories, but you really should lose that Australian accent of yours. Most scientists aren't from Australia, you know."

mcantelon 15y ago
>It's an alternative syntax Right... "alternative"... so makes sense to not give examples entirely in it unless your framework is intended solely for Coffeescript users.
- deleted 15y ago
  [deleted]
- MatthewPhillips 15y ago
  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);
  - nciagra 15y ago
    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".
    - MatthewPhillips 15y ago
      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).
    - insin 15y ago
      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/backbone.js#L1001-1010 https://github.com/documentcloud/backbone/blob/master/backbo... [2] http://news.ycombinator.com/item?id=2923694 http://news.ycombinator.com/item?id=2923694
masterzora 15y ago
They wrote you a nice library and are giving it away under an MIT license. You don't get to pick the style they use to write the examples. This is a response to something nobody's saying. Obviously if they write it they get to choose pretty much everything about it. Nobody is disputing such a thing. However, if one of the goals in releasing this is to be maximally useful, isn't the fact that raw Javascript is more readily understandable to more people a good thing to point out? Especially since it's highly likely that the team actually has the ability to do normal JS just as easily. If they disagree with such a goal, though, they can feel free to do whatever they want.
- goodside 15y ago
  Nobody who knows CoffeeScript needs to be informed that JavaScript is more mainstream.
  - masterzora 15y ago
    Perhaps not, but that doesn't necessarily imply that the use of CoffeeScript-only examples was a calculated move to reach the audience they wanted instead of whatever came to mind first. It's worth at least reminding them that JS examples might be more useful to more people and letting them decide consciously whether they care.
    - MatthewPhillips 15y ago
      They use coffeescript's class inheritance. Here's the JS that compiles down to: http://jashkenas.github.com/coffee-script/#classes http://jashkenas.github.com/coffee-script/#classes If they showed JS examples it would instantly turn everyone off. Trust me, you do NOT want to use this with JS.
- Cushman 15y ago
  This will be maximally useful if you learn CoffeeScript.
learc83 15y ago
I'd say it would be closer to the scientist giving the speech language in West Frisian to a group that's composed of 90% English speakers. Or maybe more accurately a speech in modern English to a group of early modern English speakers.

TrevorBurnham 15y ago

In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able. I think CoffeeScript is mainstream enough at this point that CoffeeScript-based documentation is a fine thing. Especially since, as they say at the top of the page, Batman.js "is written in CoffeeScript and its API is developed with CoffeeScript in mind."

MatthewPhillips 15y ago
> In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able. True, but that just basically means that using JS with Batman.js is going to be a pain. In backbone.js you also extend their base classes, but you do it in a js-friendly way (var Widget = Backbone.Model.extend). Not that there is anything wrong with a CS framework, but they should just say that it's a CS framework. The way CS compiles it's class inheritance to JS is not something I'd want to write raw.
- jashkenas 15y ago
  For the record, the way that CoffeeScript does inheritance and the way that Backbone's "extend" does inheritance is almost literally exactly the same thing. Both simply create an empty object to serve as the prototype (calling new without actually running your constructor), set up the prototype chain correctly, and stash a reference so that calling `super` is easier later on. If "Child" and "Parent" are constructor functions (class objects), then the basic pattern is this: var ctor = function(){}; ctor.prototype = Parent.prototype; Child.prototype = new ctor; Child.prototype.constructor = Child; Fun.
  - MatthewPhillips 15y ago
    This is the way JS devs have been hacking inheritance for a long time. That's irrelevant though, we're not comparing CS to Backbone, we're comparing Batman.js to Backbone. Backbone handles the messy inheritance code for you. Batman.js relies on CS for that, but a JS dev is going to have to write the inheritance code by hand. I posted the JS equivalent of their example in this thread, it's nasty.