Many organizations are finding themselves in situations where the size, performance, and complexity of their client code has become so bad that applications in the browser grind to a halt or take many seconds just to load, and they are forced to throw out their code base and start again from scratch. The term "jQuery spaghetti" is becoming quite common in the front-end community. So how did we get to this situation?
A Brief History of Front-End development for the Web
In 2005 "AJAX" was the buzzword of the Internet. While the technology behind updating content on a web page without "reloading" was not new, it was at this time that compatibility between browser vendors had converged enough to allow the web development community to implement asynchronous content updating "en masse". The performance of content delivery via the Internet was about to take a huge leap forward.
2005 was also the dawn of the server "rapid application development framework" (RAD) with RubyOnRails taking the lead followed by CakePHP, Grails, Django and many others. Before the RAD framework, developing a web application might have taken months of coding time. RAD frameworks reduced that to weeks, days, and even hours since much of the heavy lifting was abstracted out by following a few standard conventions. Anyone with an idea for an Internet start-up could have their website up and be selling to the public in a couple weeks thanks to Rails and company.
Around 2010 or so, client-side development had progressed to the point where certain UI patterns were being described for or applied to the client-side such as Model-View-Presenter (MVP), and Model-View-ViewModel (MVVM). Both are somewhat analogous to the Model-View-Controller pattern which, for a couple decades, was the one way to approach separating and decoupling dependencies among domains of application logic related to visual presentation, business logic, and data models. The Struts library for Java, and the Rails framework for Ruby lead MVC from the desktop to the web server domain. Component architecture was another way of separating application concerns by grouping together and encapsulating all logic related to a specific interaction within an application such as a widget. Java Server Faces (JSF) from Sun Microsystems was a popular implementation.
Ember.js could be described as being at the other end of the spectrum (very opinionated). While Ember.js handles management of data bindings, it requires the developer to adhere to its conventions for any aspect of an application's development. One commonality between Backbone and Ember is they have to run the show. You cannot run a Backbone app inside an Ember app, or visa verse, very easily, since both like to exert their form of control over document level interactions and APIs like deep-linking and history.
Closer to the middle, Knockout and AngularJS are both built around tight data-view binding (managed by the core) and can exist easily within apps controlled by other frameworks. AngularJS has more functionality in a smaller core, lends itself very well to creating well encapsulated UI components, and the AngularJS team, backed by Google, has announced that the development road-map will include poly-fills and full compatibility with the upcoming W3C web component standards.
If you ask any front-end developer who's drunk the Angular flavored Kool-Aid, including the author, what's so great about it, they might tell you:
"I can manage my presentation behavior declaratively, directly in my HTML instead of imperatively in a second 'tree' full of jQuery bindings."
"I can use AngularJS just for parts of my page inside my app run in another framework."
"Because AngularJS encourages functional programming and dependency injection, test driven development takes almost no extra time, and my tests have a higher degree of validity and reliability."
"I can create custom HTML elements and attributes with behavior that I define."
"I can drastically reduce the size of my code base."
"It encourages good programming habits among junior developers."
"No more hard global, application, and DOM dependencies inhibiting my testing and breaking my code"
"I can get from REST data to visual presentation much faster than the jQuery way."
What this Book Is and Isn't
At a high level this is a book about the benefits of web UI component architecture, and AngularJS is used as the implementation framework. This is a book about solving some serious problems in front-end development and the problems are described via "user story" and use case scenarios and solved via examples using AngularJS. This book is an "attempt" to be as current and forward looking that a book on rapidly changing technology can hope to be. The Angular team intends that the toolkit will evolve towards support of the W3C set of web component standards, which is in early draft. This book will explore the proposed standards in later chapters, so code written today might be re-factored into "web components" with minimal effort a few years from now.
While some parts of this book focus exclusively on the AngularJS toolkit, this is not meant to be a comprehensive guide on all of AngularJS' features, a guide on creating a full scale web application, a description of widget in the AngularUI project, or an AngularJS reference manual. The architectural concepts of UI components are applicable regardless of implementation framework or tool kit, and might help the developer write better code regardless of framework or lack thereof.