Building Web Apps with Ember.js (2014)

Preface

Building Web Apps with Ember.js

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 career—not to mention overcoming the naysayers that didn’t 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:

§ Ember’s 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 Ember’s 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.

§ Ember’s 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?”

More Than Just “Getting Started”

If you are picking up this book, we assume you have interest in building full-stack, single-page applications. In other words, we assume that you would not only like to architect and build a fully functional, browser-based application, but also connect it to a backend. That being said, this book covers all aspects of building applications with Ember. So, in addition to providing you with a complete overview of the HTML and JavaScript necessary to write on the frontend, we also include an implicit project timeline via the structure and order of the chapters, development workflow and tooling, and example backend technologies that help with getting the remotely persisted data in a format that Ember and Ember Data can easily work with.

You may be asking why we are covering all these aspects of Ember.js development. Why not just build a frontend Ember app?

Well, before we lose you, rest assured we will cover all the basics you need in Chapter 1 and Chapter 2. The approach we take in the remainder of the book will hopefully provide more value and context. We feel there are numerous example applications that already provide the necessary beginner information. These applications are very valuable, as they provide the basics and are fantastic starting points. But when you try to meet the needs of a more complex application within the context of delivering a production product, many development teams get stuck not knowing where to start, which tools to use in development, and which backend technologies should be chosen to persist data.

Navigating This Book

So, first and foremost, the demo application we will develop throughout the book intentionally covers many of the areas of development not included in most of the getting started applications. We also try to do this without creating an application that is too complicated so that we don’t lose the beginner or the developer that hasn’t yet been exposed to single-page application development in general.

Throughout the book, we provide sidebars for some of the more challenging and less documented aspects of Ember development, such as application initializers, active generation, promises, and debugging.

Establishing a pro workflow for your project can be a decision nightmare. Early on in Chapter 3, we get this out of the way and cover most of the major tooling options so that you’ll have a head start in getting you and your team set up for success.

In Chapter 4, we begin working with HTML, building templates using Handlebars.js, and extending Handlebars to create our own Handlebars helpers. The fact that we can begin with HTML is an important nuance to Ember development that works well within a project workflow that makes minimizing duplication of efforts a high priority.

Then in Chapter 5, we dive into the router, and begin to structure the various states of our application and reflect those states in our URLs. Again, the fact that we are doing this now is an important aspect to take notice of. We are prototyping, but our code will very likely survive the transition to production.

Chapter 6 fills in the rest of the blanks, introducing controllers, data binding, and views.

It is often advantageous to cache your data in client-side data stores to optimize the application so that it makes as few round trips to the server as possible. There are a number of client-side persistence solutions available. Chapter 7 covers models and Ember Data, the most official data persistence solution for Ember.

It has also been our experience that getting the backend talking to the frontend, without project churn, is one of the most difficult aspects of delivering a project. In Chapter 8, we begin building service layers that will connect your remote persistence layer to Ember’s client-side data store. Most importantly, we will do it in a developer-friendly way through abstractions, known as adapters, to ensure efficient, project-phase transitions.

Chapter 9 covers the basics of Ember components, a standardized (Web Components) approach to building functionality in a modular way, and also integration with the third-party visualization library, D3.js.

And finally, we cover both integration and unit testing best practices in Chapter 10.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

TIP

This icon signifies a tip, suggestion, or general note.

WARNING

This icon indicates a warning or caution.