Get a Customized Plan

The Fairway Technologies Blog

Slapstick - a Backbone.js Tutorial, Part 0 - the Beginning

In backbone.js, Rails 3.2, Ruby, Blog, JavaScript, software development 1 Comment


Two developers.  One Backbone tutorial.  One of us is an avid hockey fan.  The other is a bit of a sci-fi/fantasy nerd.  Therefore, it only makes sense that the app we'll be building is a fantasy hockey league website during this tutorial series.  Because seriously - who doesn't want to see Darth Vader vs. Sauron on the ice?  An epic seven game series of elves of Lothlorien vs. stormtroopers of the Death Star?  Yes, please.  I'm sure there's a "one puck to rule them all" joke in here somewhere.  I'll leave that exercise to you, dear reader.

The Players - Your Humble Hosts

Heh... "Players".  See what I did there?  Why don't we developers tell you a bit about ourselves?

  • Craig Maslowski
    • Loves hockey.
    • Is aware that Star Wars is a thing that exists.
    • Has gravitated towards dynamic languages for their elegance and simplicity - you can do a lot with a little.
    • Believes wholeheartedly in building a compelling user experience that is as easy to maintain by developers as it is to use by consumers.
  • Jeff Johnson
    • Has been to a hockey game before.  Still confused about what "icing" is.
    • Was totally crushed when he found out that X-Wings were not a real thing.
    • Spent the bulk of his career working on .NET apps in pretty much every area - server-side, database and UI (web apps and Windows forms).
    • Started working w/Ruby and Rails about a year ago, and has learned to appreciate how quickly one can get a web app up and running.

UI Code - The Schoolyard Bully

Let's just get this out of the way:  I'm rubbish at UI development.  As hard as I try to keep things organized/maintainable, it always ends up turning into spaghetti.  Specifically, it turns into eight-day old spaghetti that I left out on my kitchen counter, complete with flies and other bugs swirling around.  You know, the kind of spaghetti that you never want to touch again.  Ever.  Woe be to the developer that does have to come in after me and make some UI fixes/enhancements.  If that poor soul sits anywhere near me, I'm probably in for a beating (which would also make me feel bad, but for a different reason).

It's time for a change.  If for no other reason than I don't want to get beat up for shoddy UI code.

Growing a Spine - Backbone to the Rescue!

Righty-o - I've decided I want to make myself a better person by writing better UI code.  But where to start?  There are a number of great JavaScript frameworks out there to make UI development easier:  knockout.js, angular.js, and ember.js - and that's barely even scratching the surface.  At Fairway, we've had a lot of success with backbone.js, so that's the framework we'll be using during this tutorial series.

Why backbone?  Well, a few reasons:

  • Backbone stays out of the way.  It doesn't have a whole lot of bells & whistles - maybe not as many as some of the other frameworks mentioned above.  However, what backbone does, it does very well.
  • It's simple.  To piggyback on the previous bullet, backbone keeps it simple.  Sure, we may have to write a couple things ourselves - but that's okay.  As long as we're reasonably disciplined about it, the things we build atop backbone should be easy to maintain.  After all, that's the whole point right?
  • Annotated source.  Wanna know how backbone works?  Check it out!

Slapstick - the Demo App

The app we'll be building during this tutorial will be a fantasy hockey league website, which we've dubbed Slapstick.  Slapstick will represent a small sub-section of what would be a much larger fantasy sports site.  Specifically, the demo app will allow a user to draft a fantasy hockey team.  That team would then go on to compete during the season.  Since building a full-blown fantasy sports app would be a huge effort, we'll be focusing on creating Players (Skaters and Goaltenders, more on them in the next post) and allowing a user to assign those Players to a Team.


Here's a look at some high-level requirements for the Slapstick application we'll be building during this series:

  • A site admin can create, update and delete a Player.
  • A Player can only belong to one Team.  After he's been drafted to a Team, he cannot be selected for a different Team.
  • A user can create, update and delete his/her Team.
  • A user cannot update or delete another user's Team. That would be mean.
  • A Team can have many Players.
  • When drafting a Player, a user may only pick one Player at a time.
  • After a Player has been chosen, it should be removed from the list of available Players.
  • The list of available Players should be updated frequently, so that other users drafting a Team know which Players are still available.

What the Slapstick Demo App Is

Our intent with the Slapstick app is to demonstrate some real-world uses for backbone.  We'll use Slapstick to demonstrate how we like to organize our UI code and how we like to implement common UI features. Slapstick is a Ruby on Rails web application, umm... because.  Don't let that distract you - the focus of this tutorial series is backbone and how to use it.  The same principles should apply equally to a .NET or Java web application.

'Kay - let's get to it.  Over the course of this tutorial, we will touch on the following topics:

  • User role menu options
    • NOTE:  We won't be implementing a fully-fledged user authentication mechanism - that isn't really the point of this particular tutorial.
  • Multiple view types per resource (i.e. a "List" view and a "Details" view)
  • Filtered collections
  • Model and collection re-use
  • Applying object-oriented practices to our UI architecture

It's the last bullet that I find particularly compelling.  I've been doing object-oriented programming for a while now.  It wasn't until Craig (fellow Fairway expert) demonstrated his work on a recent project that I considered applying design patterns to my JavaScript.  I realize that JavaScript is an object-oriented language, but for some reason I've always considered OO design patterns to be more of a back-end/server-side thing.  Maybe that has something to do with the way OO design patterns are presented, but whatever.  It never really occurred to me to use a message bus to communicate data between my views.  Observers?  Service Locators?  In my UI?  Really?

You bet.  We use design patterns on the server side to keep our code organized and maintainable, why shouldn't we do the same for our UI code?  Now that I've had my eyes opened to what's possible, I want to apply design patterns to my UI code.  Not just because it sounds like a responsible thing to say, but because I sincerely believe that it's the right thing to do.

What the Slapstick Demo App Isn't

Our goal is not to write a full-fledged application.  For example, we're skipping user authentication entirely (there are about a bajillion articles written on user management).  As stated above, the Slapstick application will assume a user has already authenticated and is ready to create his/her fantasy hockey team.  Having said that, if you want to use our demo application as a starting point for anything, clone the Slapstick GitHub repo and go nuts.

What's Next?

Before we can jump into our fancy-pants backbone code magic, we'll take a look at Slapstick's domain model.  We'll take a look at the Team and the Player objects and how we persist them to the database.  This will help us identify what we need to display on our UI and the best approach to get it there. Stay tuned...

New Call-to-action
New Call-to-action