At this point of the series I really want to emphasize that the core concepts I’ve explained and will explain are not unique to Backbone; they’re unique to apps with state and dynamic views. I’m merely using Backbone as an illustration of a concrete tool that can be used to solve problems common to this type of app in general. The concept of “views” is no different.

What is a view?

If you’re coming from a different language or even a different library, you may be familiar with words like component, widget, or control. You can ask 10 engineers what they think those terms mean and you’ll likely get 10 different answers…or 30 if they think the terms are different from each other. The term view is just another one to throw on the pile and is equally ambiguous. It’s not all that unfortunate. Indeed, its usage can be quite flexible and its granularity disparate.

In the traditional web of requesting a new page for each section of a website, we may consider each page a view. Indeed, it is. In modern apps, it’s more common to have a single page and, as the user interacts with the page, portions of the page change. Those dynamic portions could likewise be called views. Within a dynamic portion of the page, there may be a toolbar that affects a list of customers. The toolbar could be considered a view. The list of customers could be another view. Each customer row inside the list of customers may be its own view. The row may contain a toggle button which is yet another view. The point is, in the Backbone world, the term view doesn’t necessary mean “a section of your website”. It can be, and oftentimes should be, much more granular than that.

At a technical level, a Backbone view is simply a JavaScript object that manages a specific DOM element and its descendants. If view A manages DOM element A and its descendants, no other view should touch DOM element A or its descendants. That’s view A’s domain. If you want to change the DOM elements of view A, go through view A’s API.

That said, a view can have sub views. In the example above, I mentioned a list of customers being a view and each customer row being a view. The customer row owns its DOM elements. The parent list view should not touch DOM elements within the customer row view. Is there a model the row should render? Pass the model to the customer row view. At that point, it’s the row view’s job. Throw it over the wall and forget about it.

With jQuery you’ll be heavily tempted to just change elements anywhere on the page willy-nilly because it’s so easy. It’s the fastest way to accomplish your task before the demo with your boss that starts in five minutes. The unfortunate truth is that structure, robustness, and scalability are not the easiest path in the short-term. In the long-term, though, they are absolutely critical to the success and future of the product and ultimately will establish the easiest path.

View granularity

So how granular should a view be? You’ll be hard-pressed to find a definite answer but here are a few guidelines. Is your view getting bloated with hundreds of lines of code? Try to break it up into smaller views. Is a single view accomplishing multiple, unrelated tasks (termed as having low cohesion)? Break it up into smaller views with distinct tasks. Do you find yourself wanting to copy-paste a portion of a view into other views? That portion should likely be its own view. Does your view manage a single DOM element that has no DOM descendants and is very simple like a single html link? It can likely be safely merged up with the parent view. When in doubt, choose many small views over a few large ones.

For you visual learners, take my current Twitter feed as an example. Look around this page and think about how you might divide it up into views and why.

I’m not going to tell you there’s a right answer, but here’s an idea of how I might divide it up:

View isolation and synchronization

We’ve talked about eventful models and collections and how they can be used to synchronize and drive multiple views without the views having to be aware of each other. The idea of view isolation and black-boxing is a very, very critical concept. So important we’re going to cover it again.

Let’s take a closer look at my Twitter feed. Let’s say I put my cursor in the “What’s happening?” textarea, type my tweet, then hit the tweet button. What should happen at that moment on the page?

1. My number of tweets on the right side of the page should be incremented.
2. My tweet should be added to my timeline.
3. The “What’s happening?” textarea should be cleared.

While coding the event handler for the tweet button, it’d be really easy to just say, “Well, I know the id of the tweet count DOM element. I’ll just grab the element using jQuery and increment the number inside it.” What’s wrong with this? We just reached outside our view and manipulated the DOM element of another view. Like I’ve said before, this will lead to a giant web of dag-nasty in the long run. Avoid it. In fact, avoid forcing the two views to know about each other at all.

Instead, let’s create a model that contains the number of tweets. Both the “What’s happening?” view and the tweet count view share the model. When the user clicks the tweet button, we increment the number on the model. The tweet count view will be notified by the model that the number of tweets has changed. The tweet count view will then update its DOM element. The views can carry on blissfully unaware of each other.

Likewise, we can have a collection containing the tweets that should show up in our timeline. We add a tweet model to the collection from the “What’s happening?” view and the collection notifies the timeline view of the addition. The timeline view creates a single tweet view, shoves the tweet model into the tweet view, then adds the tweet view’s DOM element as the first child of the timeline’s DOM element. This last part will hopefully make more sense later, but notice the timeline does not know how the tweet view is showing the tweet or what its DOM element contains. It doesn’t care. It just throws the model over the wall.

View properties

Okay, let’s get to the meat. Backbone views have several special properties:

• el – Each view has a DOM element it is managing. el is a reference to this DOM element. It can be set from the parent or it can be created and set from within the view itself.
• tagName – During instantiation, the view will determine if el was set through the constructor. If it wasn’t, the view will automatically create an element and will set it as the value for the el property. The type of element the view will automatically create is determined by tagName. By default, tagName is set to div, meaning the view will create a div element and set it as the el property if el wasn’t set through the constructor.
• className – If the view automatically creates a DOM element because el wasn’t set through the constructor, the automatically-created DOM element will receive a CSS class name as specified by the className property.
• id – If the view automatically creates a DOM element because el wasn’t set through the constructor, the automatically-created DOM element will receive an id as specified by the id property.
• model – Each view will likely be dealing with a model specified using the model property.
• collection – Or the view will be dealing with a collection specified using the collection property.

What’s so special about these properties? Let’s take a look:

var TweetRow = Backbone.View.extend({
	initialize: function(options) {
		alert('I can access this.model directly! ' +
				'The tweet text is ' + this.model.get('text'));
 
		alert('I can only access my notSoSpecialProp through options: ' +
				options.notSoSpecialProp);
 
		alert('I didn\'t even pass in el but the view made a ' +
				this.el.tagName + ' for me!');
	}
});
 
var tweet = new Backbone.Model({
	avatar: 'aaronius.jpg',
	alias: 'Aaronius',
	text: 'Honey roasted peanuts rock my sox.'
});
 
var row = new TweetRow({
	model: tweet,
	notSoSpecialProp: 42
});

Here I passed in an options object into my tweet row view. The options object is passed into the initialize() method which is automatically called by Backbone.View. Behind the scenes, though, the view first takes the special properties in the options object and merges them as first-class properties of the view. Now we can access them directly (e.g., this.model, this.el). On the other hand, anything that’s not considered special by the view is only accessible through the options object itself; they aren’t merged to the view as direct properties.

Rendering

Now we have a model or collection we’re dealing with (this.model or this.collection) and also a DOM element we’re managing (this.el). Now it’s time to render something. In JavaScript Architecture: Underscore.js we talked about how to use templates to render pieces of UI. Let’s take a look at how we would use our model and template to render a tweet row. In this example, I’m going to include the full HTML file I’m working with. This is far from a fully baked app, but I want you to get your hands on something that will actually run in a browser:

<!DOCTYPE html>
<html>
	<head>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<title>Backbone Example</title>
	</head>
	<body>
		<script src="libs/jquery.js"></script>
		<script src="libs/underscore.js"></script>
		<script src="libs/backbone.js"></script>
		<script type="text/javascript">
			$(document).ready(function() {
				var TweetRow = Backbone.View.extend({
					_template: _.template($('#tweet-row-template').html()),
 
					initialize: function() {
						this.render();
					},
 
					render: function() {
						$(this.el).html(this._template(this.model.toJSON()));
						return this;
					}
				});
 
				var App = Backbone.View.extend({
					initialize: function() {
						this.render();
					},
 
					render: function() {
						var tweet = new Backbone.Model({
							avatar: 'avatar.jpg',
							username: 'Aaronius',
							text: 'Honey roasted peanuts rock my sox.'
						});
 
						var row = new TweetRow({
							model: tweet
						});
 
						this.el.append(row.el);
						return this;
					}
				});
 
				var app = new App({el: $('body')});
			});
		</script>
 
		<script type="text/template" id="tweet-row-template">
			<div style="float: left"><img src="<%= avatar %>"/></div>
			<div style="margin-left: 60px">
				<p><%= username %></p>
				<p><%= text %></p>
			</div>
		</script>
	</body>
</html>

You’ll see in TweetRow we’ve created a render() method which populates the inner HTML of the view’s DOM element (in this case, a div that was automatically created by Backbone.View). By default, Backbone.View already has a render() method but it doesn’t perform any operation. Nothing in Backbone even calls it either. Truthfully, the render() method is more of a convention than anything, but I highly suggest you follow it. The render() method should do any work needed to update the view’s DOM element. Keep in mind that optimally you should be able to call render() multiple times if needed and your view should still render and function properly. Also, it’s recommended you return this; at the end to allow for method chaining.

There are some differences in the Backbone community regarding how render() should be called. You’ll often see examples that show the parent view calling the render() method of a child view. In our case, that would mean rather than calling render() from our initialize() method within the view we would call it later outside of the view before we append the element to a parent DOM element:

<code>this.el.append(row.render().el);</code>

I prefer to only call render() from within the view itself–never from another view–even a parent view. It’s my opinion that views should not be concerned with when other views need to be rendered or re-rendered. Others may disagree and I reserve the right to join them someday. :)

Model-View knowledge

It may be tempting to store a view or two on a model. Steer clear of this. Views should know about models and be able to bind to their events but not the other way around. This is standard MVC protocol and for good reason. Logic flow and interaction among application actors can easily become unwieldy when introducing views into models.

Event delegation

A helpful nugget Backbone views offer is event delegation. Normally when dealing with DOM element interactions you would have to query for elements using jQuery and then bind to their events. It’s not difficult, but Backbone provides a shortcut for doing so:

var DocumentView = Backbone.View.extend({
	events: {
		"dblclick"                : "open",
		"click .icon.doc"         : "select",
		"mouseover .title .date"  : "showTooltip"
	},
 
	render: function() {
		...
	},
 
	open: function() {
		...
	},
 
	select: function() {
		...
	},
 
	showTooltip: function() {
		...
	},
});

As you can see, an events property is set. Each entry could be read as follows:

• When this.el is double-clicked, call the open() method.
• When descendants of this.el matching the .icon.doc CSS selector are clicked, call the select() method.
• When descendants of this.el matching the .title .date CSS selector are moused over, call the showTooltip() method.

Another bonus about this shortcut is that referencing the this context from within the callback methods will still refer to the view–not the DOM element that triggered the event. If you’ve used JavaScript for much time, you’ll know that handling the this context can be a pain.

It’s important to understand a little about how this event delegation is set up under the hood. the constructor of Backbone.View looks like this:

Backbone.View = function(options) {
	this.cid = _.uniqueId('view');
	this._configure(options || {});
	this._ensureElement();
	this.delegateEvents();
	this.initialize.apply(this, arguments);
};

Starting with the third operation (this._ensureElement();), the view ensures that either el was passed in and, if not, will create an el on our behalf as described previously. It then calls this.delegateEvents() before calling this.initialize(). The this.delegateEvents() method is what sets up the event bindings as dictated in our events property. It sets up these bindings on whatever is currently this.el. This means if you overwrite this.el from within initialize(), you’ll need to manually call this.delegateEvents() afterward to set up the event bindings using the new this.el:

initialize: function() {
	this.el = $('<div>Overriding this.el</div>');
	this.delegateEvents();
	this.render();
},

Hopefully that will save you from pulling your hair out sometime.

Other functionality

jQuery allows us to search for elements only within this.el:

var paragraphs = $('p', this.el);

As a convenience, Backbone provides a shortcut to do the same thing:

var paragraphs = this.$('p');

With the appropriate usage of views we can build more maintainable, scalable apps. I invite you to read more in the Backbone.View documentation.

Usually when we think of collections of items in software terms with think of an array. Objects can be added and removed from an array easily enough but a native array on its own has no ability to broadcast notice of the change. Why do we care? Let’s say we’re building an RSS reader that shows the user a feed of articles from their subscriptions. The articles come from an array we loaded from the server. Each article contains a remove button next to it that allows the user to remove the article from the feed. Let’s also say in the top-right corner of the screen, separate from the feed of articles, we have a little counter that shows the user how many articles they currently have remaining in the feed. Assume that the feed has a JavaScript object managing it and the counter has a separate JavaScript object managing it.

When the user clicks a remove button to remove an article from the feed, it’s easy enough for us to remove the article from the feed itself and the accompanying array of articles, but how do we update the counter? The most direct approach is to give the feed view a reference to the counter view. That way the feed can just call a function on the counter view to tell it to refresh itself, right? Noooooooooo! Sure, it might function, but that’s a very good way to couple our views and reduce our flexibility. Our views would know more than necessary about each other. In this case, the data should drive the views instead of the views driving each other. Unfortunately, it’s difficult for our data (the array of articles) to drive the view using a native array because the counter can’t “watch” the array for a removal of an article. Native arrays do not broadcast events when items are added or removed.

You’ll notice a great similarity between what I’ve written above regarding native arrays resulting in view coupling and what I wrote in my previous post about native objects resulting in view coupling. Indeed, there are a lot of similarities and they are both resolved by implementing the observer pattern within our data structures. Just as a native object can be wrapped by a Backbone model in order to broadcast attribute changes, an array can be wrapped by a Backbone collection to broadcast additions and removals.

Eventful collections

Collections trigger events when models are added or removed. Let’s take a look at how this might look:

// Create individual models.
var taleOfTwoCities = new Backbone.Model({
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	publisher: 'Chapman & Hall'
});
 
var goodEarth = new Backbone.Model({
	title: 'The Good Earth',
	author: 'Pearl S. Buck',
	publisher: 'John Day'
});
 
// Create collection, passing in A Tale of Two Cities that will make up
// our initial collection.  Alternatively, we could have passed in nothing 
// and then called books.add(taleOfTwoCities) later.
var books = new Backbone.Collection([taleOfTwoCities]);
 
// Set up the handler for when a model is added.
var onAdd = function(book, books, options) {
	alert('Book ' + book.get('title') + ' added at index ' + options.at + '. ' +
		'The collection now contains ' + books.length + ' models.');
};
 
// Set up the handler for when a model is removed.
var onRemove = function(book, books, options) {
	alert('Book ' + book.get('title') + ' removed from index ' + options.index);
}
 
// Set up event bindings.
books.bind('add', onAdd);
books.bind('remove', onRemove);
 
// Add good earth and index 0 (before the Tale of Two Cities).
books.add(goodEarth, {at: 0});
// Remove both books.
books.remove([taleOfTwoCities, goodEarth]);
// We could have removed just a single book like this:
// books.remove(goodEarth);

I’ve added several comments inline, but let’s review what’s going on here. When we add a model to the collection, we use the add() function. Optionally, you can pass the index where you want the model to be added. We specify 0 so goodEarth will be placed at the start of the collection. By default, it will be added at the end. When we add the model, the add event is automatically triggered by the collection and any respective handlers are called. In our case, the onAdd function is called. The three arguments are:

1. The added model.
2. The collection to which the model was added.
3. Any options used to add the model.

You can add one or more models at a time.

We then removed both our book models at the same time. Even though we remove them using a single remove() call, the onRemove handler is called twice–once for each model being removed. The three arguments are:

1. The removed model.
2. The collection from which the model was removed.
3. Any options used to remove the model.

You can remove one or more models at a time. Notice that even though we didn’t explicitly pass any options object as a second parameter to remove(), the options argument coming into onRemove does exist and is populated with the index at which the model resided.

The above code produces the following alerts, in order:

1. Book The Good Earth added at index 0. The collection now contains 2 models.
2. Book A Tale of Two Cities removed from index 1.
3. Book The Good Earth removed from index 0.

What if you wanted to know when the title of any model in the collection changes? Looping through all the models and binding to each one is a pain, especially when we have to remember to bind to models being added and unbind from models being removed. Fortunately, Backbone collections bucket-brigade events coming from the models themselves which can be very handy. Let’s see how this works:

var taleOfTwoCities = new Backbone.Model({
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	publisher: 'Chapman & Hall'
});
 
var goodEarth = new Backbone.Model({
	title: 'The Good Earth',
	author: 'Pearl S. Buck',
	publisher: 'John Day'
});
 
var books = new Backbone.Collection([taleOfTwoCities, goodEarth]);
 
var onTitleChange = function(book, value) {
	alert('Book title changed from ' + book.previousAttributes().title + ' to ' + value);
};
 
books.bind('change:title', onTitleChange);
goodEarth.set({title: 'Good Earth, The'});

Notice we didn’t bind to change:title on each individual book model, but on the collection containing the book models. I even threw a little bonus nugget in there to show how we can retrieve the previous title.

Model configuration

So far we’ve been instantiating our own Backbone models before adding them to a collection. However, we can configure our collection to use a certain model class. We can then just pass a native object to the collection. Under the hood, the collection will then instantiate the configured model class for us and pass our native object into its constructor:

var Book = Backbone.Model.extend({
	defaults: {
		genre: 'historical'
	}
});
 
var BookCollection = Backbone.Collection.extend({
	model: Book
});
 
var books = new BookCollection();
 
books.add({
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	publisher: 'Chapman & Hall'
});
 
books.add({
	title: 'The Good Earth',
	author: 'Pearl S. Buck',
	publisher: 'John Day'
});

Notice in this case we actually extended Backbone.Collection and set the model property. Another option is to just set the model property on a newly instantiated collection:

var books = new Backbone.Collection();
books.model = Book;

If you don’t configure the model class, Backbone.Collection uses Backbone.Model by default. Configuring a collection with a model class may not seem very beneficial at the moment, but hopefully it will make more sense when talking about loading data into a collection.

Persistence

Similar to Backbone models, collections also have the ability to fetch data from persistence. Let’s see how this works:

var Book = Backbone.Model.extend({
	defaults: {
		genre: 'historical'
	}
});
 
var onSuccess = function(books) {
	var firstBook = books.at(0);
	alert(firstBook.get('title') + ' is of genre ' + firstBook.get('genre'));
};
 
var books = new Backbone.Collection();
books.model = Book;
books.url = '/books.php';
books.fetch({
	success: onSuccess
});

Like our previous example, we’ve configured a collection to use the Book model class. We’ve also configured an endpoint url of /books.php. When we call fetch(), the collection will issue a GET request to the endpoint. In my case, I’ve set up the endpoint to return a JSON array of books. Once the JSON is returned, the collection will loop through the array, instantiating and populating a model (in our case, a Book model) for each item. Then, the model will be added to the collection itself.

The example above will alert A Tale of Two Cities is of genre historical. The interesting part here is the genre was never sent from the server. Instead, the model picked up the default genre, historical, because we extended Backbone.Model to create our Book class and set the default genre there. Hopefully you can now see the benefit of configuring collections to use a specific model class.

Additional functionality

We’ve only covered a subset of the functionality of Backbone collections. Beyond what we’ve discussed, collections can be sorted and reset. Models can be retrieved by id. Models can be both saved to the server and added to the collection in one method call.

Collections can also be configured, for example, to load and parse data in a specific manner.

Beyond that, all collections have a bucketload of underscore functions baked in. In JavaScript Architecture: Underscore.js, I showed an example of how we can get an array of usernames from an array of user objects using the Underscore pluck() function:

var usernames = _.pluck(users, 'username');

Since collections have Underscore functions baked in, we can likewise get an array of all titles of the books in the collection in an even more concise manner:

var titles = books.pluck('title');

Nice! There are many other Underscore functions baked into collections you should check out as well. These will make your life easier and trim down your code.

Read more in the Backbone.Collection documentation.

var book = {
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	genre: 'historical',
	publisher: 'Chapman & Hall'
};

But this will soon present a problem. For illustration purposes let’s say you have view A that shows the book information and a separate view B where the user can change the book information. When the information is changed from view B, view A needs to know about it so it can update to show the new info to the user. Because our regular JavaScript object doesn’t have any way to notify view A of the change, view B would need a reference to view A so view B can call a method on view A telling it that the book object has been updated. Better yet, maybe we give view B event triggering powers and view A could just bind to view B’s events. Either way, these options should be frantically waiving red flags in your skull. Your views would now have to be aware of each other in at least one direction and that’s one direction too many. We want to free our views from the necessity of being aware of each other.

Eventful models

Backbone’s models take advantage of the Backbone.Events observer pattern implementation so we can deal with this appropriately:

var book = new Backbone.Model({
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	genre: 'historical',
	publisher: 'Chapman & Hall'
});
 
book.bind('change:genre', function(model, genre) {
	// Method 1: Use arguments.
	alert('genre for ' + model.get('title') + ' changed to ' + genre);
	// Method 2: Use book variable captured in closure.
	alert('genre for ' + book.get('title') + ' changed to ' + book.get('genre'));
});
 
book.set({genre: 'social criticism'});

When we instantiate a Backbone model and pass in the native object containing our book information, the model then wraps these attributes. Attributes can then be retrieved and stored using the get and set methods. You can set brand new attributes, unset old ones, or clear them all if you feel the need. If you try to access the attributes directly (e.g., alert(book.genre);) you’ll get an error. The get and set methods are required to deal with a JavaScript limitation in order to trigger events when attributes are changed.

By using a Backbone model our views can now watch the book directly for when the genre changes. Notice that Backbone automatically took the name of the attribute we changed, genre, prepended it with change:, then triggered an event using the resulting string as the key. By watching for the change:genre event, we can be notified any time the genre attribute is changed.

We can also extend Backbone.Model and set defaults using the defaults hash:

var Book = Backbone.Model.extend({
	defaults: {
		genre: 'historical'
	}
});
 
var taleOfTwoCities = new Book({
	title: 'A Tale of Two Cities',
	author: 'Charles Dickens',
	publisher: 'Chapman & Hall'
});
 
var goodEarth = new Book({
	title: 'The Good Earth',
	author: 'Pearl S. Buck',
	publisher: 'John Day'
});
 
// Alerts "A Tale of Two Cities: historical"
alert(taleOfTwoCities.get('title') + ': ' + taleOfTwoCities.get('genre'));
 
// Alerts "The Good Earth: historical"
alert(goodEarth.get('title') + ': ' + goodEarth.get('genre'));

Now every book that is instantiated will receive the “historical” genre by default which, of course, can be overridden.

Persistence using a static URL

How do we get data to and from a remote server? Glad you asked. Models have syncing functionality built-in. You don’t have to use it, but it can be really nice. Here’s the simplest form:

var book = new Backbone.Model();
book.url = '/book.php';
 
var fetchSuccess = function(book) {
	alert(book.get('title'));
};
 
book.fetch({success: fetchSuccess});

In this case, there’s no technical need to even extend Backbone.Model. We just instantiate it, set our endpoint url, and call fetch(). As long as the endpoint returns JSON for a single book, the JSON properties will be merged into our model. The result is a model object that then behaves just as any other Backbone model would. Note that we passed a callback function to fetch() that will be executed after a successful response. We could have also passed an error callback function to handle any issues encountered while communicating with the server.

As far as saving data, here’s how we can save a new book to the server:

var book = new Backbone.Model({
	title: 'The Tragedy of the Commons'
});
 
// Or we could've done this instead of passing it into the constructor:
// book.set({title: 'The Tragedy of the Commons'});
 
book.url = '/book.php';
 
var saveSuccess = function(book) {
	alert('book saved!');
};
 
book.save({success: saveSuccess});

In this case, the save() method will send a POST request to the server containing the book data in JSON format. If the model already exists on the server (which by default is deemed true if the model contains an id attribute), the save() method will send a PUT request instead of a POST. The destroy() method will issue a DELETE request.

Persistence using a pattern URL

While a static url may do in some cases (previously /book.php), it’s more likely you’ll have a url pattern for retrieving your models. For example, to get the book with ID = 2 your endpoint may be http://example.com/books/2. The “books” part of the path is common for all books, but the id on the end varies. In this case we could do this:

var Book = Backbone.Model.extend({
	urlRoot: '/books'
})
 
var myBook = new Book({id: 2});
 
var fetchSuccess = function() {
	alert(myBook.get('title'));
};
 
// alerts 'using url: /books/2'
alert('using url: ' + myBook.url());
myBook.fetch({success: fetchSuccess});

By creating a Book class and setting the urlRoot property, we can instantiate a book, set the id property, and call fetch(). By default a url will be composed with the pattern we’re looking for: [urlRoot]/[id]. You can modify this pattern to suit your particular needs. For example, we could set our model up to have a [urlRoot]?id=[id] pattern. We do this by overriding the url property:

var Book = Backbone.Model.extend({
	urlRoot: '/books',
	url: function() {
		return this.urlRoot + '?id=' + this.get('id');
	}
})

Notice in our examples url can be either a property or a method.

Even more likely than dealing with a single book here and there is the need to load and manage a list of books. Fortunately, Backbone helps us there too and we’ll discuss this in the next post in the series.

View state

So far we’ve talked about models in the context of representing entities. In our case, our entity is a book. However, models can also come in handy for storing view state.

Take an application like Photoshop, Illustrator, Lightroom, or pretty much any IDE where there are numerous panels that can be shown or hidden. For illustration purposes, let’s say we’re building a similar app and our requirements are that we have two panels. Panel A happens to show a particular icon on it if and only if panel B is visible. How do we notify panel A when panel B’s visibility is toggled? Suffice it to say we also have a JavaScript object managing each of these panels (one per panel).

If we take the most direct approach, we could pass panel A’s JavaScript object to panel B and when panel B’s visibility is toggled (maybe there’s some sort of hide button within the panel itself) it calls a method on panel A. Or we could just pass a function of panel A’s into panel B. Either way, that just smells bad. Again, we’ve coupled our views. This becomes increasingly problematic as we add more and more panels that need to be aware of each others’ visibility. Maybe due to UXD insanity the requirement changes such that 10 panels have to know about each others’ visibility for one reason or another. And then maybe we have a menu that shows a checkbox next to each of the names of the panels that are visible. And then for memory management purposes we decide to completely destroy and create the panels’ DOM elements and managing JavaScript objects altogether rather than just toggling visibility. Now we have this massive web of object references amongst all the various panels and when we see these new requirements an hour before launch we start to panic. You know this happens in the real world.

Unfortunately, we took the most direct, simple approach now for a lack of flexibility later. This might work in the short term, but it adds to technical debt that may become overwhelming later on.

Instead, what if we created a model to store the state of the view. Maybe we call it our panelState model and the attributes we store on the model might be presetsVisible, histogramVisible, and so on. We can then share this model with any of the panels, the menu, or anything else that might need to know about their state. We can also completely destroy a panel’s DOM element and managing JavaScript object when it’s hidden and we’re okay because rather than every panel having a reference to every other panel, they just have a reference to a single view state model that always exists.

Additional functionality

Additional functionality exists in models including validating, extracting a native object from the Backbone.Model wrapper, determining which attributes have changed, and more.

Optionality and customization

Just because Backbone gives you the ability to do all the things we’ve talked about, rest assured you’re not forced to use any of it. It stays out of the way as much as you want. If you choose, you can write your own function for loading your data wherever you want. You can opt out of using Backbone models completely. Likewise, if there’s functionality that doesn’t fit your system requirements, there are ways to customize the various aspects. I’ll leave that for you as homework whenever you need it, but these are good research techniques to get you headed in the right direction:

• Read the documentation
• Google it
• Search StackOverflow
• Post question on StackOverflow
• Ask the Backbone Google group
• Read the annotated source

Read more in the Backbone.Model documentation.

Backbone.js files and documentation can be found here or you can get involved with the source and community at GitHub. At the time of this writing, the unminified, documented code is only about 1,200 lines long so don’t be afraid to dig in and walk through the code itself. Heck, there’s even an annotated version.

Backbone.Events

At the heart of every RIA is the observer pattern (otherwise known as the publisher/subscriber pattern). The observer pattern is a design pattern that allows an object to be notified when another object has something to say, or in other words, has an event which it wishes to broadcast.

DOM elements (links, buttons, containers, etc.) already have the observer pattern natively baked in which is why you can watch for when a button is clicked without using libraries like Backbone or jQuery. However, there are times where we want our own JavaScript objects to trigger/dispatch events and we would normally have to write the implementation of this pattern ourselves. That’s where Backbone comes in. Backbone has this code for you in Backbone.Events.

Backbone.Events provides an implementation of a string-key-based observer pattern. In pseudo-code, it operates as follows. I’ve been changing a lot of poop-holes lately so let’s say I’m coding in object dad and object dad needs to know when object baby drops a turd in its deuce-trap:

var changeDeuceTrap = function() {
	baby.deuces = 0;
	baby.shutCakeHole();
};
 
baby.bind('turdDropped', changeDeuceTrap);

And somewhere within baby we have:

this.trigger('turdDropped');

Dad’s telling baby, “Let me know you dropped a turd so I can change your deuce-trap.” If mom had access to the same baby, she could likewise watch for when the baby drops a turd and change the deuce-trap too. If she does so, when the baby drops its next turd we’ll both the notified. In other words, multiple observers can watch for the same event.

You might think this is magic but it’s not. What’s happening here is dad is literally passing the changeDeuceTrap function to baby. Baby then maintains an array for turdDropped and adds changeDeuceTrap to the array. If another observer chooses to listen for the same event, that observer’s function will also be added to the same array inside baby. When baby drops a turd, it iterates through the array calling all the “callback” functions it contains.

While we can easily give any object event-triggering powers using Backbone.Events, don’t worry about it for now. Backbone.Model and Backbone.Collection already have Backbone.Events baked in and those are the main types of objects triggering events in our applications.

I should mention jQuery has an observer pattern implementation of its own but we’ll be focusing on Backbone.

Read more in the Backbone.Events documentation.

I’ve accepted the honor of speaking at this year’s conference and will be speaking on JavaScript on Wednesday at 10:50am. As you probably know, the Adobe community has really been shaken up over the last few months. Adobe’s position on Flash and Flex has morphed and many engineers are taking a closer look at other technologies. While JavaScript holds a stigma of being a red-headed step-child from the same orphanage as ActionScript 1, many see it as the inevitable future of the web. While the language hasn’t evolved much, libraries and patterns have shaped up to help provide an environment conducive to building robust, dynamic enterprise apps. We’ll discuss these libraries and patterns, learn how they relate to Flex, and make a comfortable home away from home.

Many of the concepts will be pulled from the JavaScript architecture series I recently started. Also, while I am a software engineer at Adobe, my thoughts are my own and do not represent those of Adobe.

Array/Object/Function manipulation

As we create software is seems like we come in contact with the same patterns over and over. Usually, we end up re-writing them over and over as well. Take an array of user objects, each with a username property. We need an array of all the usernames from all the objects. So, like many times before, we create a new array to populate, create a for loop, snag the object at the current index, grab the username and push it into the array.

To me, that’s boring. It’s mundane. Underscore makes it fun again. With Underscore, we just use pluck():

var usernames = _.pluck(users, 'username');

Ah…concise, fast, and boilerplate is gone. Want to find all objects within an array that pass a specific test? Use the filter() function. Just want a reference to the first one that passes the test? Use the find() function. Want to retrieve the union of two arrays, that is, retrieve a single array of all unique objects contained within multiple other arrays? Try the union() function. Merge properties of multiple objects into a single object? Use extend().

Once you grasp the power of Underscore you’ll find yourself being more productive with less code while having more fun. Some have called it the bowtie for jQuery’s tux. I concur.

Templating

The template() function is only one of the many listed for Underscore, but its purpose is very important.

Let’s say you’re building an app to manage your todo items. When the user creates a todo, it’s your job to create a todo row for the view. And maybe you want to allow them to select the row using a checkbox, delete the row, or edit the row in-line. Without using a templating engine, you might end up with something like this:

var todoTemplate = '' +
	'<div class="todo ' + (done ? 'done' : '') + '">' +
		'<div class="display">' +
			'<input class="check" type="checkbox" ' + (done ? 'checked="checked"' : '') + ' />' +
			'<div class="todo-text"></div>' +
			'<span class="todo-destroy"></span>' +
		'</div>' +
		'<div class="edit">' +
			'<input class="todo-input" type="text" value="" />' +
		'</div>' +
	'</div>';

This is troublesome. First, your html is likely buried somewhere inside your JavaScript code. This makes re-skinning an app much harder since you now have to track down all your html strings scattered throughout your logic. Second, concatenation takes time, is risky, and falls under the categories of mundane and frustrating. You have to deal with escaping and indentation. Your IDE probably isn’t going to color-code, code-hint, or auto-indent as well as it could if it were plain html. It’s easy to make a mistake and, since JavaScript is loosely typed, you might not find these mistakes until runtime. Also, if you dish your code off to HTML/CSS gurus, they now have to deal with these problems too.

Templating engines provide a better way of managing the situation. What if we added this at the bottom of our body tag instead:

<script type="text/template" id="item-template">
	<div class="todo <%= done ? 'done' : '' %>">
		<div class="display">
			<input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />
			<div class="todo-text"></div>
			<span class="todo-destroy"></span>
		</div>
		<div class="edit">
			<input class="todo-input" type="text" value="" />
		</div>
	</div>
</script>

There are a few things to note here.

• The code is plain HTML except for those things that can be dynamic which are inline (<%=...%>).
• The dynamic portions reference a variable called done. We’ll talk about that in a minute.
• The code is wrapped in a script tag with a type of text/template meaning it won’t be interpreted as JavaScript (the default script type) by the browser. If it were, the browser would throw errors.
• The script tag has an ID which allows us to later access its content.

At this point, the code inside the script tag is just innate text. The browser won’t try to execute it or anything of that nature. That’s where Underscore’s templating engine comes in. In our app JavaScript code, we can then take action like this:

var template = _.template($('#item-template').html());

The $('#item-template') code uses jQuery to reference the script element. Calling html() on the element then returns the inner html of the element–in this case the html that will represent a todo item. Here comes the underscore templating engine: _.template(). At this point a compiled template has been built. This allows us to now pass a context object into the compiled template to produce html we can then use for our todo item. This might look like so:

var todoHTML = template({done: true});

The portions of the template that depend on the done variable will be evaluated using the done property on the context object. The resulting todoHTML will be a string of html that looks like:

<div class="todo done">
	<div class="display">
		<input class="check" type="checkbox" checked="checked" />
		<div class="todo-text"></div>
		<span class="todo-destroy"></span>
	</div>
	<div class="edit">
		<input class="todo-input" type="text" value="" />
	</div>
</div>

You can then use jQuery to create an element out of the html. It’s as easy as

var element = $(todoHTML);

I should mention that a portion of this code is pulled from Backbone.js‘s Todos example.

Template management

You might rightfully be wondering how this is scalable if you start to have hundreds of templates in your html file or how you might be able to load them asynchronously only when needed. If you’ve asked yourself these things, congratulations! These are questions architects should be asking. We’ll talk about how to manage this in a later post.

Templating syntax

Underscore by default uses ERB-style template syntax (<%=...%>) which to me feels nasty and isn’t fun to type. You can change that to some other style like {{...}} as follows:

_.templateSettings = {
  interpolate : /\{\{(.+?)\}\}/g
};

Much better.

Other templating engines

The concept of a templating engine is not unique to Underscore or even JavaScript. There are many others in many languages. I feel the most notable ones in JavaScript outside of Underscore are Mustache.js and Handlebars.js. I use Underscore because it’s a top-notch templating engine, includes other Underscore functionality I use anyway, and it’s a dependency of Backbone.js which we’ll be discussing in a later post.

Where to use templates

After reading this, you may think templates are only appropriate for elements whose count is undetermined until runtime like our todo items. If so, may I suggest considering that everything should be a template?

What if you took everything in your body tag, broke it up into reasonably small templates, and left your body tag with nothing in it except for your templates? What if each DOM element and its contents produced from each small template were managed by a single JavaScript object? What kind of freedom would that bring your code? Could you move these components around more freely? Ship them over to be used in a different app? Would they be less coupled from one another and provide stronger APIs? Could you more appropriately add, remove, re-arrange, and manipulate these components rather than having a big fat HTML file written up front? Could you provide your users an all-around more dynamic experience? I hope you catch the vision. In upcoming posts we’ll see how this takes shape.

In my experience and the experiences of others, far too many JavaScript noobs hear all about the powers of jQuery and how it can do this and that and pull rabbits out of a hat. I do not dispute its awesomeness. What follows, though, is that some developers feel it is the answer to all their problems–including architecture. They then start busting out apps only using jQuery with little or no thought given to architecture because, in their mind, they’re already “using a framework” or “using an architecture.” This may work for a brochure website with little interaction or state, but not for large, enterprise apps where greater structure is needed.

We’ll dig deeper into application frameworks, architecture, patterns, and all that juicy stuff later. For now, I just want you to have an understanding of where jQuery fits into the picture lest you stray before we get into the meat.

What does jQuery do?

It abstracts the mess that is the DOM. DOM stands for Document Object Model and consists of elements and element hierarchies that make up a web page. When manipulating elements on a page (form elements, containers, text, etc.), you somehow need to be able to find these elements, size them, position them, style them, animate them, add them, remove them, watch for events from them, and a plethora of other operations. Without jQuery, this is a mess. For one, the DOM and its APIs are quite poor in general. Second, standards love to be ambiguous and browsers love to stray from standards. jQuery abstracts this into simple-to-use APIs so you can be more efficient and waste less time dealing with browser inconsistencies and the dag-nasty that is the DOM.

jQuery also provides a great set of utilities for making ajax requests and dealing with objects, arrays, strings, and more. Many other utilities and widgets are built on top of jQuery including jQuery’s own jQuery UI.

Who uses jQuery?

jQuery is very popular. According to BuiltWith, jQuery is used on over 24 million websites. To avoid copyright infringement I won’t include their chart here, but I advise you to take a look if you’re interested. You’ll see that over half of the top 10,000 sites use jQuery and this number is growing at a very steady pace.

Content Delivery Networks

This popularity not only exemplifies itself with a thriving community but also reaps the benefits of exposure through a content delivery network. A CDN exposes assets at strategic places both geographically and network-topographically on well-tuned servers. This boils down to three points of awesome:

1. The files will be delivered quickly.
2. Some browsers limit the number of concurrent connections to a given hostname. A CDN will be a different hostname from that which hosts your main application assets resulting in additional concurrent pipes open for transferring data to your user’s browser.
3. Browsers cache files based on their URL. If a user goes to Site A that loads its jQuery from CDN X and then navigates to Site B that also loads its jQuery from CDN X, the user’s browser will likely not have to load jQuery a second time since it can be retrieved from its cache.

Google provides the most popular CDN for jQuery. You can see the most popular libraries it hosts as well as the URLs you can use to load them here. Given that many of the web’s largest sites use the Google CDN for jQuery, it’s very likely your users will be able to take advantage of cross-site caching.

Many of the other libraries we will be talking about may not be hosted by Google, but are hosted by cdnjs.

Justin Meyer, the main guy behind JavaScriptMVC, said something I feel is a very simple principle every architect should ingrain into their brain:

The secret to building large apps is NEVER build large apps. Break up your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.

I don’t think any other principle will carry more weight in architecture–especially with JavaScript. You may be thinking, “Oh, my application isn’t big enough to follow this principle.” Re-think this. Every application I’ve architected–even the smallest of the small–have benefited from this principle. The pieces of your application must be decoupled and cohesive as much as humanly possible to withstand the test of time. Each piece should be as black-box as possible–pass information over the wall and the next component does its job. And I don’t just mean different views of your app; I also mean individual, small components of your views, models, and everything you build. This presentation on Scalable JavaScript Application Architecture does a great job of explaining these principles in more detail.

When you think of JavaScript apps you may think of a few gigantic, spaghetti JavaScript files and a few beefy HTML files and a mess throughout. You might even think of fat strings of html text hand-concanated, escaped, and declared right within your JavaScript. Escape this mindset. That, indeed, is a rightful stigma of JavaScript apps because so many exist that fall into this category. We’re not going to be following that trend. We want to favor many small classes, files, and HTML templates over a few large ones. Small classes lead to small scope. Small scope leads to better maintainability and easier debugging because there is less your mind needs to comprehend. It also encourages strong, well-planned APIs and low coupling.

You may be thinking, “But JavaScript doesn’t have namespaces and everything’s asynchronously loaded and depends on everything else! And what about all the requests to the server? And how do I get all those HTML templates into my app? This is going to be a nightmare!” Don’t worry about it. We’ll get there. Don’t fall into the trap of making excuses for poor design just because you’re in JavaScript.

Admit what you don’t know

The only thing that’s guaranteed not to change is change. Therefore, never act like you know how your app will grow and change. Nicholas Zakas said it well:

The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don’t know everything, you begin to design the system defensively.

Naming conventions

There are many conventions in JavaScript–some more popular than the others. I find it important to maintain consistency with most JavaScript code out there. Unfortunately, I haven’t found empirical evidence showing which conventions are most popular, but I have done some rudimentary research and will propose a few seemingly most-popular conventions. Again, these are only suggestions. The most important point is that you agree on a standard as a team and stay consistent.

• Names of directories and files should be all lowercase. Add hyphens between words.
• Variable names should be camelCase.
• Objects (functions) meant to be instantiated should start with a capital letter.
• Private scope doesn’t exist in JavaScript except through closures. See the poorly-named module pattern for more info but I don’t really love the consequences of the pattern. Instead, I suggest prefixing names of members meant to be private with an underscore. It doesn’t provide true privacy, but it’s a pretty solid red flag that you shouldn’t use it publicly.

Testing

Strongly-typed languages (e.g., Java, C#, ActionScript 3) specify the type of each variable throughout the application. This means the compiler can raise red flags when you try to use an object in a manner that wasn’t intended by its type. In essence, strong typing can be considered to be a bunch of built-in, simple unit tests that are run each time the app is compiled.

JavaScript is not a strongly-typed language but instead is a very loosely-typed language. It’s much easier to make mistakes by using objects in ways that weren’t intended or just fat-fingering a variable name and you won’t find out about it until you run the code and see the error (a good IDE can also help). For this reason, I believe testing is even more important in loosely-typed languages.

There are many JS libraries available to help you test your code. QUnit seems to work well and is popular. If you don’t already have a favorite, I suggest to start there and research outward.

JsTestDriver can also be very useful (and happens to have a QUnit adapter). JsTestDriver allows you to run your tests within a variety of browsers. This can be very helpful since browsers aren’t consistent in their implementation. For example, I might write code using myArray.indexOf() which will work on most browsers but not older Internet Explorers. By running your tests within actual browsers these issues will crop up and you’ll find out about them before your users do.

Strict mode

The 5th version of ECMAScript (the standard upon which JavaScript is based) provides an option with which you can tell browsers to be more strict with your code. Newer browsers will respect it while older browser will stay lenient. Why would you want browsers to be more strict with your code? Because you want to decrapify your code. Strict mode provides the following (copied from MDN):

• Strict mode eliminates some JavaScript pitfalls that didn’t cause errors by changing them to produce errors.
• Strict mode fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that’s not strict mode (Firefox 4 generally hasn’t optimized strict mode yet, but subsequent versions will).
• Strict mode prohibits some syntax likely to be defined in future versions of ECMAScript.

I highly recommend invoking strict mode to keep your code squeaky clean.

Code Analysis Tools

A couple popular code analysis tools exist to likewise help decrapify your code. They scan your code and raise flags when they see you’ve done something dangerous or undesirable. They mainly focus on syntax, style, and structure. They do not verify that your logic is correct.

The first is JSLint. It’s “the original”. The second is JSHint. JSHint explains the difference:

JSHint is a fork of JSLint, the tool written and maintained by Douglas Crockford.

The project originally started as an effort to make a more configurable version of JSLint—the one that doesn’t enforce one particular coding style on its users—but then transformed into a separate static analysis tool with its own goals and ideals.

Both tools have online versions where you can copy-paste a snippet into a textarea and have the code analysis do its thing. This works okay for bits of code here and there, but even better is setting up the analysis code to run on your full app. Both tools have integrations to you allow you to analyze your app’s code from your IDE or command line. On our team, we run the tool from an Ant script that we can then run from the command line, our IDE, or our deployment servers. I highly recommend you run these tools often right off the bat. Note that each have flags you can set to be more or less strict in its analysis.

For the past several years I’ve been an architect in enterprise-level RIAs. This is a fancy way of saying I oversee the design and construction of apps that are web-based but have a lot of the same characteristics as desktop applications. Some of the applications I work on are in fact desktop applications but heavily communicate with the web. The line becomes very blurry, but the main point is–I deal with applications which in my world are quite different than what is often considered a “website” even though they both live within a browser.

There are others in the industry who do what I do or would like to do what I do. Of those there are some who are new to JavaScript. This is my intended audience. An architect arriving at JavaScript for the first time has a lot to learn and many decisions to make. As the lead architect on a product and being fairly new to JavaScript (well, modern JavaScript) I likewise had to go through this process and have spent countless hours re-learning JavaScript, testing IDEs, discovering communities, exploring deployment procedures, learning what questions to ask, evaluating libraries (mvc, dependency management, dom manipulation, testing, deployment, utilities) and putting all these things together to lead a team and produce an application worthy of enterprise consumption. My hope is to help others along the way.

You might think this is a broad effort, but my goal is not to simply regurgitate everything I’ve learned but to help boil things down to what’s important to get you on your way. We’ll discuss core principles that are common in dynamic apps regardless of the languages or libraries used. However, to illustrate them and hopefully give you enough of a concrete example to help you hit the ground running, I’ll be using specific, hand-picked libraries for this series. In your own research you may find other libraries are more appropriate for your particular project. That’s fine; the principles in this series are still valuable and applicable.

Choose wisely

JavaScript is merely a language. HTML is, for the most part, a set of dilapidated, relatively primitive components. To reduce boilerplate, abstract browser inconsistencies, and provide engineers with higher-level tools to be more productive, all kinds of libraries have come out of the woodwork. Because JavaScript and HTML leave out some basic structures and components that are so commonly needed, these libraries often overlap in functionality and features. This also means some don’t play well together. This is both exciting because you have so many options to choose from and yet frustrating because you have so many options to choose from.

As an architect, specifically in an enterprise setting, these decisions will be very important and can ultimately determine the fate of your product. If I were farting around on a side-project, I’d probably feel comfortable picking the most awesome-sounding libraries and running with them. In the corporate world though, we have to answer some important questions: Is our product part of a larger suite? If so, what is the rest of the suite using? If the rest of the suite were to standardize on a particular library, how hard would it be for us to refactor? What if we chose a “full-stack” library and a portion of it is or becomes inferior to other options? What’s the chance that a different library may overtake my library in community and technical progression? What’s the community like around those libraries? Which libraries are gaining steam or fizzling out? What’s their learning curve? How easy is it to hire developers for these libraries? It’s a very different ballgame so take care in your decisions. In my case, I found the best option was to pick a handful of high-quality tools with healthy communities that worked well together but were decoupled in their implementations. Grooveshark provides a very interesting related case study.

Rolling your own

There comes a time in every developer’s life where we get caught up in rolling our own libraries. Maybe we think our work is superior, maybe we don’t do enough research on what’s already available, or maybe there’s just one small thing that isn’t quite right in a library so we rewrite it from scratch. I’ve done it and you likely have too. When determining what your team will use, it’s very important to keep in mind some of the significant benefits of going with a wisely-chosen 3rd-party/open-source library:

• Free development resources
• Free documentation
• Free bug fixes
• Free testing by automated tests and other community members
• Collaboration amongst generally intelligent industry leaders
• A place to learn more and ask questions

Far too often I’ve seen very intelligent architects roll their own libraries because they feel their skills are superior or are OCD that the libraries work exactly like they want and carries no extra baggage. Very often, if that architect were to stay on the project forever, this would probably work out quite well and the product would be successful. In reality, the architect leaves. Almost always they were time-crunched and didn’t fully document the library, set up testing, or cross-train their co-workers. They developed the library for the purpose of fulfilling the specific needs of a project and even though the library may have been a fantastic work of art, the engineers left with that work of art don’t understand its intended usage or how to make modifications. From there, the engineers begin using it incorrectly and if they have questions they have nobody to ask and nowhere to look except for undocumented, increasingly morbid code. Inevitably, the product starts its death-spin, the engineers blame the architect that left, and technical debt grows until the product declares bankruptcy. At this point it’s time to rebuild or sink.

Truthfully, most of the fault really does fall on the architect. The role of the architect is not only to code awesomeness, but also to understand the software circle of life and make wise decisions.

Don’t get me wrong–there is a time and place for rolling our own libraries. If you come across this time and place, make sure you have the necessary resources behind it. Do it right. Where possible, create the libraries as though other companies might also use them. Document them–not only in code but in API documents, examples, and tutorials. Open-source them on GitHub and make it a home for external resources to congregate around and contribute. Pay attention to others’ contributions and incorporate their ideas and code where possible. Many if not most of the great libraries available today originated from this concerted effort.

One last note about open-source libraries. The historical perception is that these libraries are siloed away in some remote part of the web and their developers are anonymous and unapproachable. This usually isn’t the case anymore–especially with GitHub. Oftentimes if you have a legitimate concern the community is very approachable and will respond quickly and respectfully. A great example of this is when I recently found that underscore.js lacked a function for finding the symmetric difference between multiple arrays. I provided the underscore.js community an example of where it would be beneficial and five days later it was added to the trunk with a unit test and documentation. Good libraries have good communities. Choose wisely.

We don’t need no stinkin’ frameworks!

A long-standing debate among some in the community is whether formal frameworks are needed at all. The argument against frameworks usually goes something like, “We’re all smart engineers–we can architect an app well without having to resort to a formal framework.” That may be true, but it’s usually a fallacy. If it’s not a fallacy, it’s very difficult to do with most teams. If you are able to successfully execute on that concept, you very likely unconsciously re-wrote large portions of a framework you could have used in the first place.

When working in a team, a framework provides an important benefit of consistency and a game plan. Good frameworks generally prescribe examples of best-practice usage but provide some flexibility in implementation. No doubt engineers can abuse the best of frameworks, but having a blueprint of how architecture and implementation should, in general, be performed goes a long way in getting everyone on the team to have a consistent vision and understanding.

Learn JavaScript

Learning JavaScript is not a one-time event. You’ll be learning over a long period of time, but it’s important that you actually make it a priority to learn the language. A lot of the libraries we’ll be looking at do a lot of abstracting for you–keeping you away from the nitty-gritty of JavaScript. That’s very helpful and can speed up your development dramatically, but it should not be used as a crutch. Far too often people learn libraries but not the language. This is a mistake and will bite you in the end.

I’ll be the first to admit that JavaScript has some really nasty parts. Frankly, it’s not my favorite language. But you’ll be living in it. Accept it and learn how to take advantage of its good parts and avoid its bad parts. To that end, I recommend starting with Douglas Crockford’s JavaScript: The Good Parts. Ironically, it’s a small book and very approachable by JavaScript noobs.

IDE

Get yourself a quality development environment. If we’re talking web we’re primarily talking HTML, JavaScript, and CSS. There are all kinds of free web-oriented IDEs (Aptana comes to mind) but I recommend you pick up a copy of WebStorm by JetBrains. A good IDE will give you great JavaScript code-hinting to shield you from some of the woes that come with the dynamically-typed language. Other things I look for: coding workflow, local and remote debugging, version control integration, remote server deployment, plugins, etc.

Have comments or questions? Post them below!

Over the last two years we’ve become frequent fliers at your hospitals. Our daughter has an undiagnosed Leukodystrophy and, as such, reacts abnormally to or has a difficult time fighting off the variety of ailments that beset her. She is tube fed, immobile, and unable to speak. A week ago we were on a family vacation in Idaho and she became very sick. She began vomiting frequently and couldn’t retain the smallest amounts of liquid. Her skin felt hot and she appeared extremely lethargic. We took her to the IHC emergency room in Burley, ID to get her the help she needed.

Three times while in the emergency room we recounted the events that had occurred leading up to our arrival and the history of our daughter’s Leukodystrophy. Eventually tests were ran which showed low glucose levels and an extraordinarily high heart rate–both symptoms of dehydration. She was given fluids and glucose to a point where she seemed to be responding well enough for us to cut our vacation short and make our way back home. They directed that if there were any problems in the meantime to be sure to take her to the nearest emergency room.

The trip back home is approximately four hours. During the trip home she moaned in a way that seemed to express pain but we figured it may be a result of the trauma she had endured over the past day. When we got home, she was acting very similar to how she was before we took her to the hospital earlier. She was very unresponsive and resisted opening her eyes or making any movement. When we tried giving her a few drops of water in her mouth using a wet sponge she immediately vomited. Again her heart rate was elevated and her skin felt hot. It was obvious something was wrong and she needed liquids fast. We rushed to the IHC emergency room in American Fork, UT about five minutes away.

The lobby was empty and it did not appear as though many, if any, patients were being attended to within the ER. I showed the secretary our unresponsive daughter and requested that fluids be provided quickly and that we already knew she was dealing with dehydration. Again we were asked to explain the events that had occurred–not only since our trip to the IHC hospital earlier in the day but also the events previous and the circumstances surrounding her Leukodystrophy. We were asked to explain the same to the nurse who took her vitals, weight, etc. Ten minutes had passed and no liquids had been requested.

We were brought back to the emergency room where a different nurse cheerfully chatted with our newborn son who we had brought in the car seat, asked what his name was, and when he was born. By all means, she had a heart of gold and I would love to bring in my photo albums so she could get acquainted with my family tree, but my daughter continued declining and, as though I should have to point out, we’re in the emergency room! Again, we were asked to recount the history of events and details of her Leukostrophy. We made sure this nurse, too, was aware our daughter needed liquids ASAP.

Twenty minutes into our hospital visit the doctor came in. Again we were asked to recount the history of events and details of our daughter’s Leukostrophy. A half hour had passed since we entered the emergency room and no fluids were to be seen. On the flip side, I was able to partake in the reminiscing of recent class reunion hilarity that ensued at the nurse’s station while my daughter continued on the decline. Nay, not only that, but I was able to graciously provide my credit card to pay for care we had not yet received, look for insurance cards that turned out to already be in the system, and for the fourth time answer such urgent and diagnostic questions as “And who’s your employer?”

I pitched a fit. I made a scene. I’m sincerely not one to get upset easily or desire to make any sort of disturbance especially in a place of healing. But that day I did everything in my power to ensure your employees knew we were in an emergency room and there was an emergency to be treated. The doctor’s response: “Your child isn’t going to die if we don’t give her fluids right away.” Is that so? Were those your findings the last time you treated an undiagnosed Leukodystrophy patient suffering from severe dehydration the previous doctors thought they had under control? Why are we in the emergency room at all then? Who cares if her energy is sapped to render her unable to avoid aspirating her own vomit? Who cares if her system continues shutting down or her body starts eating away the little muscle she has. Send us home with a bottle of water or maybe I can call in my extended family and we can all kick back and talk about who our employers are! Hell’s bells–I’d venture at least 95% of the people going into the emergency room wouldn’t die if we sat on our hands for a while. Let’s all go have a coffee break, shall we?

After finally getting her hooked up to fluids and reviewing some of her tests she took an ambulance ride to the IHC Primary Chidren’s Hospital in Salt Lake City, UT. We repeated the routine. Two more times we described the events. Two more times we gave the history of her Leukodystrophy. Two more times I answered who my employer was and a handful-dozen other questions I had answered several times previously that same day. Our daughter was hospitalized for three days following to be treated and recover from what appeared to be an intestinal virus.

I realize this may be entirely ignored or we may be discredited as over-dramatic parents. Or, on the other hand, you might consider the improvements that could be made, a higher standard that could be achieved, or that patients might be able to arrive at your hospitals with the expectation of timely treatment and professional service.

Sincerely,

Aaron Hardy