Viewing the ‘JavaScript’ Category

JavaScript Architecture: Backbone.js Models


Updated Aug 11, 2012 to reflect current library versions.

Models contain the data or state of an application. Examples of a model would be a book, car, or customer. A book model would contain typical attributes of a book: title, author, genre, and publisher. A regular JavaScript object could contain this data like so:

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. Continue reading »

JavaScript Architecture: Backbone.js Events


Updated Aug 11, 2012 to reflect current library versions.

Backbone.js is an MVC framework for JavaScript applications (although some legitimately argue it’s not technically MVC). Its purpose is to provide structure to your application so it can be modular, decoupled, and scalable. If you’re not sure why you may need an application framework, please read JavaScript Architecture: The Basics first. Backbone is not a dom manipulation utility, templating engine, or UI component library.

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.


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. Continue reading »

Speaking on JavaScript at 360|Flex 2012


It’s almost time for another 360|Flex conference! This conference will be held in Denver, Colorado, April 15-18, 2012. Get your tickets fast while discounts are available! It’s always a huge opportunity to learn new things and get in touch and have fun with the community.

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.

JavaScript Architecture: Underscore.js


Underscore.js, like jQuery, is a toolbox of utilities. Check out the website for a list of functionality it provides, but I’ll split it into two parts:

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. Continue reading »

JavaScript Architecture: jQuery


jQuery is not an application framework. It is a toolbox–a set of utilities. If it could receive the label of “framework” at all it would be a utility or widget framework–not an application framework.

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. Continue reading »

JavaScript Architecture: Organization and Quality


Never build large apps

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. Continue reading »

JavaScript Architecture: The Basics


This post is intended to be the first of a series. I want to be clear about what it entails and its intended audience.

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. Continue reading »