Interview with Paul Miller: maker of Chaplin and Brunch

Today we have very special guest. He is a passionate open source developer with many projects out there. Particularly two stand out: Chaplin an MVC framework built on top of Backbone and Brunch a build tool, Yeoman/Grunt alternative. These projects are used by thousands of developers and helps us to make better software. For example, the new Delicious, that well-known dinosaur from Web 2.0 era, is now blazingly fast thanks to Chaplin MVC framework and Brunch.

Say hello to Paul Miller. Today we will ask him about his projects, future plans, and how to become a better JavaScript developer. Don't switch the channel.

Hi, @paulmillr. Please tell us more about yourself. What do you do, where you live, and how did you end up in JavaScript development?

I do mostly tools for web devs these days, but i’m also launching non-dev-related projects.

I started doing JS a long time ago, just when I started doing web dev. Back in 2011 i’ve thought web applications are the future and started doing them, discovered Backbone and stuff.

{{ screenshot: Chaplin }}

How did the Chaplin project get started? Can you tell us a brief history of it?

Matthias Schäfer had separated some parts of moviepilot.com into one reusable framework and named it as Chaplin.

I’ve came to the project after like two weeks and instantly saw Chaplin potential, then decided to help with its development.

Thanks to Chaplin community, first year was very productive — lots of companies had adopted Chaplin and contributed. I hope this year will be even better.

We both agree that Backbone framework is awesome. It is simple and flexible unlike Chaplin. It's awesome too, but in order to use it, you should learn Chaplin conventions, CoffeeScript, RequireJS, AMD, Brunch, and others. Why should developers do that? What benefits they would achieve by using these technologies?

Backbone is cool, but it lacks opinions. It just gives some core concepts, you’re supposed on your own to figure out how to use them and where.

I really like what Chaplin does here. It pushes some best practices that made us productive. This makes your code consistent, clear and very maintainable. It is easy for new devs to continue making your app after that.

Learning today’s web application stack is not as hard as it seems. In my experience, team which was working with Django had been able to learn the whole stack and write production-quality code in something like 2-6 weeks. This included coffeescript, backbone, underscore, jquery, chaplin and brunch. Quite a lot when you think about it.

You might think memory management is a thing of a past but it's definitely not. How should one approach this topic? How to write better JavaScript code that doesn't leak too much?

Controlling life cycle of components in your app really matters. In order to avoid leaks it’s important to pick a right architecture that will have some concept of manual memory cleanup.

Everyone makes mistakes, so it’s better to make them as loud as possible for early detection. Freezing (Object.freeze()) / sealing (Object.seal()) your objects and ECMAScript 5 strict mode helps with that. When the object becomes unneeded and you’re ready to pass it to garbage collector, delete all properties from it, unbind all handlers and freeze it. If anything from outside will try to change object somehow, you will get a nice exception.

{{ screenshot: Brunch }}

A few words about your future plans. What can we expect from Chaplin, Brunch, and Ost.io?

Brunch will get source maps support. This is really much requested feature. Today there are no solutions for headless automatic compilation of files with source maps. You still need to manually do most of the job.

As for Chaplin, we want to release stable version (1.0). Before that we hope to incorporate view transition support and AJAX handlers auto-abortion / stacking. Backbone doesn’t help us much here, just like with memory management. And, of course, we want to improve documentation. Screencasts and more examples would be nice to have.

I hope to push ost.io as a default application example for todomvc “successor” — taste.js. We’re still discussing possibilities, though I persist on the forum. My main points:

  • it is more complex than todomvc and many other examples. CRUD, authentication, consumption of REST API data, app-wide persisted views — everything is here. Some folks say that app should show more than this and i’m absolutely open on any new features and ideas.
  • it is real-world. Actual people provide support for their stuff there. I don’t like the idea of building another application just to show how tech behaves.
  • it is working right now. Ost.io demostrates real code today, the spec is there too. Real artists ship™.

And traditional question. As we are a JavaScript libraries site, please name a few libraries a frontend developers should look at to gain new superpowers.

I’m a big aficionado of ultra-small libs that do only one thing these days. Chaplin stack is not like that, though. So I prefer small components to full-size libs.

But there are some common libs that really help me.