Sadly, A brunch that doesn't involve bacon

Brunch!!!

How it starts

When Snip.it first launched, we had a fairly typical Rails stack, with the majority of view logic taking place on the server side. And like many web applications, as the application grew, we came to increasingly rely on Javascript for user interactions.

Whether it’s a simple ajaxy button or a complicated piece of form validation, if you’re not careful, your oh-so-DRY code on the Rails side soon becomes filled with duplicated client side functionality.

A move to Backbone.js

For us, the solution seemed to be the easy choice of moving to a more structured JS framework like Backbone.js. Backbone would allow us to move all the view rendering to the client side, and allow Rails to handle formatting and controlling the data coming from the database. But when the time came to get started on the implementation we soon found ourselves having to make even more decisions about directory structure, compilation, minification and deployment.

If you’re familiar with Backbone.js, then you’re probably also familiar with the amazing Addy Osmani and his book Backbone Fundementals. The advanced section has a great breakdown on ways to structure your app, as well as how to go about setting up tools like Require.js. And while this is a a great guide to handling some of the finer points of Backbone.js development, we weren’t in the position to make these decisions this early on in our development.

Brunch to the rescue

At it’s core, Brunch is just a Node.js based build tool for developing and deploying HTML5 apps. But like Rails, when you create a new Brunch project, you get a pretty awesome set of defaults for building your application.

Brunch handles our four main areas of concern. Compiling server side code (eg. Coffeescript/Roy), wrapping multiple files as common.js modules, building/minifying the final output, and allowing team members to quickly get started developing.

Rolling this out to the team is as simple as having each member ‘npm install’ the latest version of brunch, and then executing the brunch CLI tool. And since it’s based on npm, you can even explicitly list out your dependencies in package.json much as you would in a Gemfile.

What you get is a single compiled JS file which includes all the libraries you depend on, your backbone application code, and the common.js wrappers. And while you’re developing, Brunch will watch for changes and automatically recompile the code.

Where do we go from here

This is a big topic, and we’ve decided to publish a series of blog posts about Brunch and our development process. In the next few weeks, we’re going to touch on the following issues.

  • Death of a hashbang
  • Building on top of the Brunch API
  • Migrating from Rails to Rails/Backbone.js
  • Playing with alternate setups like Chaplin

Resources for your perusal

Photo courtesy of Martin Cathrae

Published: Friday, March 30 2012
Author: Mark Percival