Announcing the first release of batman.js(batmanjs.org) |
Announcing the first release of batman.js(batmanjs.org) |
I got zero value out of this lead.
When you launch a product like this, please tell us why we'd want to use this. As developers, we don't have a bunch of time to parse your project notes. "It's like XXX, but offers these advantages..." At this moment, I don't know what batman.js is actually useful for!
We designed everything around a number of primary goals such as convention over configuration, HTML-based views, and the principle of least surprise. This is something we're using at Shopify in our future projects, so it's meeting those goals while coming out of real work.
If you want more info, the features page (http://batmanjs.org/features.html) has a list of everything we're trying to do, and the examples page (http://batmanjs.org/examples.html) has a few usage examples. There's still only a couple, but I'm working as quickly as possible to build out the gallery.
And of course, let me know if there's anything else I can answer about the framework. I hope that helped clear it up a bit, though!
That sounds like a pitch I would give a non-techie manager or client. Someone who's been around computers enough to know that javascript is the thingie that makes web pages do stuff.
Your target audience is developers, yes? We can take it. The first thing in your pitch should be how it helps, not "We'll save you lots of time, we promise. Trust us!"
Can I suggest that in the website header you include some sort of one-line description, like 'the javascript web application framework', or similar and more creative?
Maybe this blurb from the documentation could find its way to the hoe page:
batman.js is a framework for building rich single-page browser applications. It is written in CoffeeScript and its API is developed with CoffeeScript in mind, but of course you can use plain old JavaScript too.
Still nada. What does it actually do? A framework for doing what w.r.t. rich JavaScript applications? Is this like Cappuccino? How does this "make development as fast and as painless as possible for developers and designers while giving them lots of power"?
After giving up on the blog post, the index page of batmanjs was great though. I think it should've been linked to instead.
The name is amusing, but a bit silly --
"What are you guys using for all of your cool AJAXy stuff?"
"Batman."
# Create our application and namespace.
class Alfred extends Batman.App
@global yes
@root 'todos#index'
# Define the principle Todo model with `body` and `isDone` attributes, and tell it to persist itself using Local Storage.
class Alfred.Todo extends Batman.Model
@global yes # global exposes this class on the global object, so you can access `Todo` directly.
@persist Batman.LocalStorage
@encode 'body', 'isDone'
body: ''
isDone: falseCoffeeScript is not JavaScript. If it's a JavaScript framework, please give code examples in JavaScript.
body{ color: #000000; }
Thankkk you!
Other than that, looks cool! Definitely will be trying it out in my projects and reporting back!
Great to see it released! One thing I always find helpful is a comparison/discussion of where it fits with others in this realm.
congrats, Jack
Anyway, it's like the love child of Backbone.js and jQuery Mobile, and perhaps more intuitive than both. I'll definitely play with it some tomorrow to see whether it holds up to its promise.
I think all of the JS MVC frameworks will be short lived. Someone (hopefully) will develop with a real soup to nuts solution that will make writing a front end heavy app simple. In Rails, I can see it being as easy as "act_as_front_end" somewhere, and the app automatically serves up your JSON to a generated frontend that mirrors your Rails app. I know that would be a hard thing to make, but this is where things should converge.
More details in the readme here: http://github.com/Shopify/batman/blob/master/README.md
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."
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.
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."
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.
Or maybe more accurately a speech in modern English to a group of early modern English speakers.
Right... "alternative"... so makes sense to not give examples entirely in it unless your framework is intended solely for Coffeescript users.
Sure, you could make your backend in plain Ruby, but if you learn to use Rails you can do things quicker.
Sure, you could make your frontend in plain JavaScript, but if you learn to use batman.js you can do things quicker.
Shopify would use this to write the client-side parts. We can now save on a lot of server-side rendering of pages every time a request happens; instead we just send back JSON and Batman.js knows how to change the page accordingly.
We’re already using it internally for non-core projects like our phone support system (Batman.js + Faye + Adhearsion) – it makes for a really responsive web app that’s easy to maintain.
Expect to see this in the core Shopify product very soon :)
Nick gave a nice demo at JSConf earlier this year: http://blip.tv/jsconf/jsconf2011-nick-small-5293530
Not sure what all these negative comments are doing here. Feels like half the people are asking for somebody to hold their penis and the other half is crying because they can't read Coffee-Script.
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.
The first version of Batman was written in plain Javascript, but Shopify has really been falling in love with CoffeeScript, so we decided to rewrite it before it was released.
Batman.coffee is more correct but sure doesn’t have the same ring to it…
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;
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.
* A subclass that inherits the parent's implementation of the constructor function, unless overridden.
* A named function for your class object, without IE scope leaks.
* A way to call super that's as easy as `super()`.
* Inheritance of the parent's own properties (unfortunately via copying).
* ... which enables helpful metaprogramming within class bodies. For example, Batman's own `event` decorator:
use: @event (times) ->
return false unless ... (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;
})(); 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)
}
})
var Shopify = Batman.App.extend({
root: 'products#index'
, resources: 'products'
})
[1] https://github.com/documentcloud/backbone/blob/master/backbo...
Would makes sense to say this on the front page of the project. Most Coffeescript projects do.
Also, you aren't entitled to dictate instructions to other people who are giving you the benefit of their hard work. It's rude and obnoxious.
There's no mention of CoffeeScript anywhere
It's in the 2nd paragraph of the docs. Not prominent, but somewhere.
CoffeeScript is not JavaScript
Technically true, I suppose, but they are beyond related.
If it's a JavaScript framework
Maybe it's a CoffeeScript framework? My sense is that at the very least, the use of CoffeeScript is an important aspect of the project.
Where were you looking?