Posts Tagged ‘dom’


JavaScript Architecture: Backbone.js Views

01.08.2012

Updated Aug 11, 2012 to reflect current library versions.

Tech-agnostic concepts

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


JavaScript Architecture: Backbone.js Events

12.23.2011

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.

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


JavaScript Architecture: jQuery

12.13.2011

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 »