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."
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.
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.
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.
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).
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."