Building Web Apps with Ember.js

Chapter 5. Building the RocknRollCall Prototype: The Router, Routes, and Models

If we set out to build a “single-page application,” we’ve sure nailed that so far. But if we want our application to actually do anything, we’re going to need to represent a few different application states, or what used to be described as “pages.” In modern web applications, it should still mean a change to the value in your browser’s address bar, most of the time.

For a few years now, HTML5’s History API has made it possible—or at least far easier—to change the URL without reloading the page.  What has not been so easy, without frameworks like Backbone.js and its kin, has been using that URL as a convenient way to serialize the state of your application. Serializing application state has always been tricky. Giving the user an easily portable token that both represents state in a high-resolution manner and is meaningful has been largely unheard of. The URL that you expose to your users is just such a token. They can bookmark it, send it to their mobile phone/tablet/refrigerator/friend and even tweet it. Consider Google Chrome, which uses URLs to grant access to its own settings panel. If a family member using Google Chrome asks you where they can disable cookies, you can send a link to that pane in the settings interface. Good luck doing the same with a native application.

Ember’s Routing mechanisms offer a robust toolkit for building a complex matrix of states, and their APIs and conventions offer ...