Jesse Cravens - Building Web Apps with Ember.js

• 2014-07-07: First Release

Welcome to Building Web Apps with Ember.js! This book is largely about building production-capable, browser-based appplicatons. Some might call these single-page apps while others say HTML5 apps, client MVC apps, or rich Internet apps; but in the end, these types of applications are one and the same: the web browser is the application platform, and the server provides remote service endpoints. After years of writing and using many of the solutions available to manage complex applications of this type, we have settled on Ember.js as our primary toolset. In this book, we will attempt to both teach you what we know about Ember, and, along the way, demonstrate for you why it has become our primary toolset for building web applications.

In 2005, I (Jesse) discovered JavaScript and the XMLHttpRequest object while working at a digital agency that deployed .NET and Drupal applications with rich, Flash and web frontends. At the time, JavaScript was a disrespected toy language used to sprinkle functionality onto the top of traditional web applications. Ironically, much of the JavaScript work I did then involved using flashvars to create a bridge between PHP and browser-based Flash applications.

But, at the time, Flash frontends were a necessary evil. Browsers were largely incapable of supporting rich, interactive experiences, and respectable JavaScript libraries like MooTools, YUI, and Dojo were only beginning to mature.

As I began taking additional risks by using more and more JavaScript in my applications, I started to find other like-minded developers that also believed that browsers would evolve and that JavaScript was more than just a toy language. We believed JavaScript was a full-featured, object-oriented, professional language that was capable of being used to build high-performing production applications. A strong community began to evolve, fueled largely by pioneers like Douglass Crockford, John Resig, Paul Irish, and Christian Heilmann to name a few, and eventually frontend developer became a professional job class in many organizations.

In 2007, I took my JavaScript skills to the enterprise. I was hired to begin building a complex, rich Internet application within an enterprise J2EE stack. This introduced me to many of the most common challenges presented by large-scale development: lack of JavaScript and frontend expertise, server-centric web legacy, complex cross-browser and mobile-web fragmentation compatibility requirements, and lack of provisioned desktop and development tooling for frontend developers, just to name a few. Being faced with all these limitations was some of the most challenging work of my careernot to mention overcoming the naysayers that didnt want to see the end of safe, traditional web applications.

Over the next couple of years, I focused solely on implementing and deploying a solution that was in many ways before its time. Many of the tools that are available today were nascent, or nonexistent at the time, including client MV* libraries, client-side routing and object relational mappers (ORMs), JavaScript templates, JavaScript promises, async flow control libraries, and web components. Nevertheless, my team and I dreamed up and implemented custom solutions within the parameters of the project timelines and requirements. Overall it was a success, and our client MVC framework still remains in production today.

Since 2009, I have worked on numerous applications using Backbone, Angular, and Ember. But today, I often recommend Ember.js to the clients I work with. This is primarily due to the fact that the conventions support well-known web application development patterns that I have custom written or pieced together from multiple open source libraries. Here, are the high level concepts that, in my opinion, make Ember so valuable:

• Embers object model supports a classic and well understood, object-oriented pattern of class inheritance through extend, object initialization, getters and setters, and class monkey patching.

• Ember models, controllers, and components extend the Object class, which ensures that these objects inherit Embers powerful default data binding.

• The router supports complex nesting for URL-driven applications that manage application state in a conventional way that can be understood by those with web-server-routing backgrounds.

• Recently, build, workflow, and testing tools in Ember have matured and become intuitive.

• Embers only dependencies are on jQuery and Handlebars.js, two very well-known and documented libraries.

• Finally, the community is vibrant, passionate, and extremely active.

In late 2012 and 2013, Thomas Brady and I found ourselves working on numerous ambitious web UIs in our work at frog design. Despite the nascency of the framework at the time, we felt Ember was the right tool for the job. We believed in the direction the framework was heading and in the community of talented developers behind it. At times it was frustrating, but in the end, I find myself saying all the time, Can you imagine what it would take to do this in another framework?