molily Navigation

Chaplin as a Fully-Tested, Reusable Application Library

It’s been three months since we released Chaplin, an application architecture for JavaScript applications using the popular Backbone.js library. Since then, Chaplin evolved significantly.

First of all, Chaplin took off as a community project. Two maintainers joined the team, Karel Ledru-Mathé and Paul Miller. More than 900 people are watching Chaplin on Github, and several people contributed bug reports and pull requests.

After the release of Chaplin, I held several meet-up talks on Chaplin and similar topics: at the Ruby User Group Berlin, at Berlin.JS, at AdCloud in Cologne and recently at the apps.berlin.js meet-up.

More importantly, Chaplin evolved into a library. The initial release was a just small example application which demonstrated the architectural ideas we had developed for moviepilot.com. It also contained some utility code which helped us with asynchronous programming. In the example application, general framework code and application-specific code were mixed up.

Therefore our first goal was to split up this code. Chaplin is now an external, reusable and generic library for JavaScript applications. It still consists of several AMD modules internally, but it can be included as one super-module (chaplin). Chaplin now has a build script which packages all core modules into one CoffeeScript or JavaScript file, minified and gzipped if you like. (See also: Building Chaplin.) Of course, you can still use the r.js compiler to package your application code together with Chaplin’s modules.

The original Facebook example application is now located in a separate repository. Most of the utility code was also moved to this repository. We’re going to create some more repositories, for example a simple Hello World boilerplate and a comprehensive API documentation.

Once we released Chaplin, the code was quite stable because it was derived from the field-tested moviepilot.com codebase. But Chaplin went its own way, diverged and also served as a testbed for new approaches. So it was necessary to write a full test suite which automatically checks the Chaplin features. For any software project nowadays, test-driven development is essential. In short, we’re proud that Chaplin now is almost completely unit-tested with Jasmine. (See also: Running the tests.)

So Chaplin made a huge leap forward, but there is still much to do. We overhauled the README to reflect the code changes, but we need an extensive documentation which explains the architecture, provides examples and describes all core module features. If you would like to help, feel free.

I’m also glad to see that projects like Marionette, Thorax and Layoutmanager are thriving and prospering. They are adressing similar problems, incorporate great ideas and improve the JavaScript and Backbone ecosystem as a whole. That’s why my latest talk wasn’t about Chaplin alone, but introduced three libraries and compared them in a non-competitive way.

So far, thanks a lot to everyone who contributed to Chaplin, attended the talks, spread the word and so on.

Follow ChaplinJS on Twitter to get updates.