Ember.js is “a framework for building ambitious web applications.” In more specific terms, it is a collection of libraries, abstractions, and conventions for dealing with the challenges of building single page web applications.
Out of the box, Ember provides:
Ember is open source and community-driven. One of its guiding principles is that the abstractions it provides should be extracted from real-world applications, rather than being based in theory. In the words of co-creator Tom Dale:
Yehuda and I have been extremely aggressive about getting real users of Ember involved in the design and maintenance of the framework. This keeps us honest and makes sure features we add are not things we think are neat but are driven by real problems developers are hitting today.
— Tom Dale, answering on Quora, 21 Nov 2012
In the early 1990s, Tim Berners-Lee experimented with hypertext, a way to link documents that was proposed in the 1940s. From this work came the first websites and browsers, and in 1993 the first standardized version of HTML. By 1995, an early browser company named Netscape had created JavaScript, a scripting language for browsers.
JavaScript and web technologies became foils of several corporate interests, and consequently innovation stagnated. For nearly a decade there were significant challenges writing JavaScript for the browser. Feature implemention by browser makers was notoriously buggy and inconsistent. In the mid-2000s, the emergence of several new browsers encouraged the creation of and adherence to standards. Popular JavaScript libraries began to emerge, providing better APIs and easing the writing of cross-browser code.
The 2008 release of Google's Chrome spurred competition in JavaScript performance, and in over 5 years, there has been an order of magnitude (or greater) improvement. With stable, consistent APIs and amazing performance, JavaScript is a much different tool than it was only two or three years ago. Most browsers now follow "evergreen" release cycles with automatic updates, and legacy browser usage is rapidly dropping. This trend, in combination with the massive distribution of browsers on mobile and tablet devices, makes the platform incredibly attractive.
Web application development (with a few exceptions) has in the past been page-based. Each click results in a fresh page of HTML being rendered on a server and sent to the browser. With a robust and performant client-side platform, web applications can be implemented as single-page apps. Clicks trigger JavaScript events that may fetch data from a server or update the interface. In many ways, this brings web development closer to traditional desktop or mobile development.
Ember started life in SproutCore, the history of which can illuminate the design of Ember and other single-page application frameworks. SproutCore dates back to 2007, and is best known as the framework behind Apple’s MobileMe (now iCloud) suite of web applications. It was created to build desktop-style apps in the browser and took a widget-based approach to user interface. In SproutCore, HTML and the DOM are abstracted away — the API for managing widgets replaces the web itself as a UI layer. Other frameworks from this era include Cappuccino, which went further than SproutCore in an effort to mimic the Cocoa desktop application framework. Not only did Cappuccino hide HTML and CSS from the developer, it also substituted JavaScript with an Objective-J superset.
SproutCore’s creator, Charles Jolley, worked on the framework at Apple until 2010, when he left to form Strobe Inc. He was joined by, amongst others, fellow Apple engineer Tom Dale and prolific open source contributor Yehuda Katz, known for his work on Ruby on Rails and jQuery. As SproutCore’s development progressed, the team’s goals diverged. SproutCore had powerful bindings, observers and well-designed MVC underpinnings, but it also focused heavily on an interface design that mimicked desktop applications and lacked an intuitive templating system. In 2011, a complete rewrite was announced under the name "Project Amber." The plan was to take the best of SproutCore, marry it with declarative auto-updating templates using Yehuda’s Handlebars library, and put HTML and CSS front and center as the presentation layer.
When I met SproutCore, I realized that it provided a more powerful observer library than anything I was considering at the time for the data-binding aspect of Handlebars, and that SproutCore’s biggest weakness was the lack of a good templating solution in its view layer. I also rapidly became convinced that bindings and computed properties were a significantly better abstraction, and allowed for hiding much more complexity, than manually binding observers.
After some months of retooling SproutCore with Tom Dale to take advantage of an auto-updating templating solution that fit cleanly into SproutCore’s binding model, we reached a crossroads. SproutCore itself was built from the ground up to provide a desktop-like experience on desktop browsers, and our ultimate plan had started to diverge from the widget-centric focus of many existing users of SproutCore. After a lot of soul-searching, we decided to start from scratch with SproutCore 2.0, taking with us the best, core ideas of SproutCore, but leaving the large, somewhat sprawling codebase behind.
— Yehuda Katz, Announcing Amber.js, December 2011
A naming conflict between Amber and an existing JavaScript project (Amber Smalltalk) resulted in Amber being renamed to Ember shortly after the announcement.
The final piece to Ember’s origin story is the formation of Tilde. In August 2011, as work was getting underway on Project Amber, Strobe was acquired by Facebook. Yehuda Katz, Tom Dale, Leah Silber and Carl Lerche, determined not to let their team be scattered to the wind, struck out on their own to found Tilde Inc. This small band of prolific open-source developers, eschewed VC-funding in favor of bootstrapping their new company. Tilde now splits its formidable powers between consulting, open-source and working on their own products, such as the recently announced Skylight, itself an Ember app.
In its home independent of venture capital and giant corporations, Ember has become a true community project. At this time, the core team is nine strong, and the main repository has seen contributions from over 275 developers around the globe.
Ember is designed for building long-lived apps in the browser that rival native apps in terms of performance, robustness and sophistication. Building this kind of application requires techniques and mechanisms that HTML and JavaScript do not natively provide. Fortunately, the patterns and techniques to achieve these goals are well understood in native development. Ember borrows concepts from native MVC frameworks like Cocoa and WPF, mixes them with the lightweight approach of web frameworks like Backbone, and optimizes around the URL-centric nature of the web platform.
Ember is by no means the only project seeking to advance application development on the web. Alongside the aforementioned Backbone, other frameworks include Angular, Knockout, Batman and Spine, to name but a few. While these frameworks and their communities share common goals, their approaches and philosophies differ, and all have their advocates and detractors. There are no shortage of flame wars… err, comparisons… between the frameworks, so rather than compare them all side-by-side, let's focus on Ember's strengths:
Obviously web development, and even just JavaScript development, is an extremely broad topic. There are a lot of "tools of the trade": HTML, CSS, the browser, a version control system, and so on. Ember is a framework that works in conjunction with all of these tools. Discussing these other tools in detail is outside the context of this book. Therefore, at least a basic working knowledge of the tools mentioned in the following points is recommended:
Since Ember applications are just JavaScript text files that run in a browser, any desktop operating system will do. Many JavaScript developers prefer Unix-based operating systems such as OS X or Linux, but Windows will do just fine as well.
As for browser compatibility, Ember supports every modern browser, all the way back to Internet Explorer 6! Currently, many Ember and JavaScript developers prefer to use Google Chrome during development for its speed and debugging tools. We will be using the Chrome JavaScript console to demonstrate how Ember works, so be sure to have Chrome installed.
Git is the version control system of choice for Ember and most Ember projects, and they are often hosted on Github. If you haven't already installed Git on your computer, you will want to do so now.
While Ember applications run in the browser, they usually load and save data from a web server via HTTP. Ember can connect to any website with an API for accessing data, so even old legacy platforms at work can serve as the backend for a new Ember application.
When starting a new server-side application intended to provide an API to Ember, choosing a modern framework with good support for RESTful JSON APIs is highly recommended. For further discussion of APIs and accessing data-layers from Ember, see the models chapter of this book.
Some web frameworks provide preprocessing tools for JavaScript code, making concatenation of files, dependency management, and preparation of assets for production easy. The ember-rails project, for example, hooks into Rails’ asset pipeline to compile Handlebars templates and concatenate/minify Ember application code. Similar libraries exist for other frameworks, such as django-pipeline and Convoy for Node.js. We call these asset management tools build pipelines.
For long-lived projects, providing Ember applications a stand-alone codebase is a good choice. This formalizes the separation of back-end concerns and font-end concerns, and results in a more flexible codebase over time. The problems of asset management remain though, and there are several build pipeline tools that address these issues without involving a web framework. Many are based on Node.js and the Grunt task engine, including Ember-App-Kit and Yeoman. Others exist with differing approaches, among them Brunch, rake-pipeline, ember-runner and Broccoli.
In the following chapters we’ll walk through Ember’s overarching design, then dive into its constituent parts. In part two, we’ll put these tools to work creating a fully-fledged application.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.