Fighting crimes with Batman.js - Interview with Nick Small of Shopify
There are many MVC frameworks for client-side development. According to GitHub stats, AngularJS is now the second most popular JavaScript MVC framework right after Backbone. What made Angular popular? I'd say people like it because of its declarative style and bidirectional data binding in views. But did you know that there is another framework that provides similar binding features and a lot more? It is called batman.js. In many cases it looks a bit like AngularJS. As you know, there is Google behind Angular, but batman.js is maintained by Shopify (also no stranger to open source) and looks really promising.
Batman's views rely heavily on HTML data attributes. Compared to Angular Batman is less modular, placing its namespace in global scope for easier access. batman.js is written in CoffeeScript and shares the principle of "convention over configuration" inspired by Ruby on Rails. This makes its code more compact and readable, much faster to write and prototype, and easier to jump into a new project. The downside is that the learning curve now includes learning all of the conventions that the framework provides.
{{ screenshot: batman.js }}
Let's take a quick look at some code from both frameworks. Here is a controller built both in AngularJS and batman.js. (I will use CoffeeScript in this example)
As you see they are pretty similar, but personally I find batman.js's code a lot cleaner.
One problem with batman.js is the documentation. Batman in general has a bit of a smaller community and fewer tutorials available. Still, I tried it once for my project Mailican and I must say the experience was really positive.
After I discovered Batman.js, I was really interested to speak with its creator, Nick Small from Shopify.
Hi, @nciagra. Why did you decide to build your own MVC framework?
We set out to rebuild the Shopify merchant interface as a JavaScript application. We wanted a super-fast runtime experience, the ability to prototype new features more quickly, and a more responsive and interactive user interface. Think back to those early Wild West days of JavaScript MVC frameworks. Off the top of my head, at the time, there was JavascriptMVC, Backbone and early code for SproutCore 2.0. Of these, we liked Backbone the most, but knew that it wouldn't give us nearly enough support to easily build our huge application. That was the idea; to build a framework that would let us work the way we want with our designers and developers, support us as the app grew to hundreds of files and classes, and follow the ideas inherent in our culture of how a Shopify app should be developed.
How hard is to maintain an open source project of that size? Are you the only core developer?
It's definitely a challenge. batman.js is developer as an extraction from Shopify 2, so all of the many many developers we have here are potential contributors, and many of them are. There is also a growing number of external contributorsâworking on some really amazing projectsâwho send us some great pull requests. I'd say the biggest challenge for us is managing our time between batman.js and the Shopify product, but it does mean that all of the code going into batman.js is code being used in our production app.
Why did you choose CoffeeScript for your project? Wouldn't plain JavaScript provide more control over the code?
Take your pick: we like writing in CoffeeScript better, Shopify is a Ruby shop and CoffeeScript looks familiar to Rubyists, it results in far less and far cleaner code, it allows us to build more expressive DSL's, and there is almost zero overhead or downsides to using it. Anything you can do in JavaScript you can also do in CoffeeScript, so no, it wouldn't provide any additional control. Plus, you can drop into JavaScript at any point (we don't).
Probably many JavaScript developers start with Backbone and end up with building their own framework architecture. What issues they should keep in mind developing a MVC framework? Maybe you could share some tips and advices?
We've learned a ton about framework design and the JavaScript environment throughout this process. I can definitely recommend building your own framework that suits your own needs if one doesn't already exist and if you have the time, energy, and follow through to dedicate to it. That said, there's a lot of knowledge that Shopify and all the other framework developers have generated that you lose out on by rolling your own; I'd definitely also recommend trying out a few that appeal to you and reading through the code to try to avoid some of the most common pitfalls in framework development.
What are the future plans for batman.js?
The next release of batman.js is going to be a big, breaking release. We've decided to clean up a lot of API's and make everything more consistent. We're also going to bring everything in line with Rails 4 and remove a lot of old cruft and code paths that either aren't being used any more or just don't belong in the core of the framework. You can see some early results of this in master right now. Performance and documentation are also huge concerns. We have a dedicated suite of tools for testing batman.js performance, and it's getting really, really good. Documentation is also extremely important to us, and we'll have some really neat developments on that front to go along with the new version!