Published on Apr 28, 2015

A special philosophical aside on when it's appropriate to use Ember (spoilers: it's almost anytime you're making a web app).

There's also a huge listing of all the things Ember and the surrounding ecosystem do for you- things you don't have to learn.

This is a good one to send to friends who are ember-curious.



Hey, I'm Jeffrey Biles from Today I'm going to give you an overview of Ember.js and the surrounding technologies.

This is Not a Coding Screencast

Normally in these screencasts I would show you a bunch of code and teach you how to write code, and if that's what you're looking for there's over 30 other screencasts on this website that can help you do that.

But today, in just 20 minutes (oops, it was 33…), I want to give you a complete overview of Ember in the ecosystem, so I don't have enough time to in the depth in one technology. But I've got just enough time to talk about many technologies, and the philosophy that holds them together.

This is (Natural) Philosophy

Let's start with the quote from a philosopher, my favorite natural philosopher Isaac Newton said, "If I have seen further it is by standing on the shoulders of giants." What he means by that is that, he's obviously a very smart guy and he's done all these amazing things but doesn't mean he's the smartest person whoever lived just because he discovered something new. There are a lots of smart people that came before him and he's saying that, because of those previous discoveries that's why he could make the discoveries that he made.

Discoveries like gravity, a lot of our everyday physics, different light refraction's, these are all things that Newton discovered, but they're only possible to discover because of the work that happened before. He's standing on the shoulders of these giants of science and philosophy. That's what he meant.. but when I imagine that, I always imagine this-- literal giants standing on the literal shoulders of other giants (except, in my imagination, I'm better at Photoshop and I can actually put their feet on their shoulders).

Let's apply this to technology. Not-Isaac-Newton said, "If I have made awesome web apps it is by Embering on the shoulder of giants." Let's look at what makes up that stack of giants that Ember stands on.

The Giants Below Ember

At the bottom we have NAND gates and we think of NAND gates as just this logical abstraction and we can do that because the abstraction works so well. NAND gates are actually these master works of quantum mechanics, electrodynamics, all the stuff that we never have to think about. Of all the abstractions we're going to talk about today this is by far the most obstructive because we're not even realizing all the stuff that's happening so that we can have NAND gates.

So we have NAND gates. On top of that we've got some microchips and we got some very creative people combining NAND gates and other types of gates into microchips. Then we have an assembly language to talk to microchips and C that compile down into assembly language. Then we have JavaScript which compiles down the C and we have jQuery on top of that which covers over some of the uglier parts of JavaScript as well as the DOM. Then on top we have Ember standing on all these giants.

That's a nice story we can tell but there is a little problem with it. Namely that NAND gates were not invented for the express purpose of building Ember. As a matter of fact, C wasn't build for the express purpose of building Ember. So It's not a stack of giants, it's a tree of stacks of giants, with various branches that do different things and multiple things building on one abstraction.

Now, if you are familiar with evolutionary biology then this may look familiar to you because it looks very similar to the tree of life— and that's no accident. Because each technology much like each species fulfills an ecological niche.

No Technology is Always Best

There are some species that are really good at building at skyscrapers and writing books and extending their niches, those are humans. If you're in a place where you can use a bunch of tool, use your big old brain then it's really nice to be a human. That doesn't mean humans are strictly better just that we're better at certain niches.

For example if we're underwater it is distinctly not better to be a human. If you're underwater, it's much better to be a fish, and then, if you are in a live volcano, you definitely don't want to be a human or a fish. However, there are certain types of life— very simple, very specialize types of life — that can survive in an active volcano.

This maps on to various technologies, where Ember… it's not necessarily the best for every situation. It's very flexible and it's extremely powerful but if you want to build a blog, or live inside an active volcano, or create a sales force— you can guess what's whatever at that. But, for making general purpose web apps, Ember is where it's at.

The View From the Top

We have the stack of technology for making general purpose web apps and Ember is at the top. What's it look like from there? It can be a little bit dizzying because there are so many abstractions that maybe new to you that you didn't even know existed before, or maybe you knew they existed but you're used to writing them by hand, so some of this maybe really unfamiliar first, but I want to convince you that it's worth it.

Let's take a look at a bunch of the things that you don't have to worry about when you're writing in Ember. Let's start of with what Ember CLI gives us.


Here's how you get started with Ember, you say, "npm install ember-cli," and then you type in 'ember new' then the name of your app. That gives you a complete ember app in just two lines… and here's all the things that you don't have to do. The things that are already done for you just in those two lines. Let's go for them one by one.

Package Managers (npm and bower)

It's popular today to complain about npm and bower but if you remember back in the battle days you had to include JavaScript library files in the HTML of your web page. You not only had to do that for other people's JavaScript, you had to do it for your own. You had to download and place in actual files, and then dependency management was a nightmare.

Npm and bower have solved this, and Ember CLI wraps a further layer on top of that, where you don't have to worry about getting started, it does that for you and includes everything you need for your basic Ember app.

File and Directory Structure

It also gives you a file and directory structure. Jackson Pollock may or may not be beautiful depending on who you ask but you definitely don't want a Jackson Pollock in your code base. You want this nice thing to the left, which is everything in its place. Ember gives you a file and directory structure that's common between different apps between different coders. This is extremely valuable for three reasons.

The first, the most obvious, is so you know where to put something. There's no wondering about which folder it should go in. This is the most obvious but it's also the least useful.

The second is that you know where in the past you have put something so you can find it again.

The third is that someone else knows where you have put stuff. By having this common structure it save you, your future self, and your colleagues a lot of time.

Build System (Broccoli)

It also gives you a build system. This is Gruntfile, and as you can see it's pretty complicated. A grunt is definitely better than doing everything by hand, but let's see if we can get it simpler.

This is the broccoli file in an Ember CLI project. Now, the top two lines and the bottom line are doing basically everything that this previous Gruntfile did. All the lines in between are things that we had to include. This is everything that's needed for an actual production app that has been in production quite awhile, and there's only one command that I need to learn— app.import.

We're taking a lot of abstractions, a lot of complicated abstractions and simplifying it down to one abstraction that does a lot of work for you. This is a pattern you'll see over and over when working with Ember and Ember CLI. Let's see what else Ember CLI has done for us already.

JSHint and LiveReload

JS Hint is included automatically, that can help catch syntax errors before they become a problem. JS Hint… normally you have difficulty remembering when to run it, but luckily for you Ember CLI runs it every time.

Every time… When is that? Because we have Live Reload it's every time you make a change to a file. Not only will it run JS Hint but it will also refresh in the browser.

ES6 Modules

Ember CLI also gives you a module system. Popular module systems in the past few years have included common JS, require JS and a couple others. The one that's going to use most often in the future is ES6 modules because it's going to be baked into the language.

You maybe wondering, "Well, how are we going to use ES6 modules if ES6 hasn't been released in all browsers yet, if that feature isn't there yet?"

ES6 Transpilation (Babel.js and Broccoli.js)

We have ES6 Transpilation using Babel and Broccoli.js so not only can you use ES6 modules, you can use any ES6 feature that is currently part of Babel. These modules and transpilation worked together with the file structure so that you really don't have to do much or anything to get this going.

There is one small downside of using ES6 modules, and that’s that there's a little bit of boiler plate, the import and the export at the beginning and end. That's why Ember gives you Generators.


You just type in 'ember generate’, then the name of type of file you want, and then the name of the file, and it will give you the JavaScript.
In the case of a component and several other types it will give you the handle bars. Then it will generate a test which does have quite a bit more boiler plate that it saves you from writing.

Yes, it does generate a test but how does it run it?

Test Runner

Ember CLI gives you a test runner just by typing in 'ember test.' That will run them once and if you type 'ember test' with the server option it will run it on file change, thanks to Live Reload. It uses QUnit as the default, and you can create acceptance test like that using the Ember generators (you’re starting to see how all these things work together to provide this amazing experience). You can type in to generate a test and it will generate it.

Of course not everyone likes QUnit, so if you don't like it you can just replace it with something else and you can do that thanks to add-ons. These are the three lines that takes to replace Ember-CLI QUnit with Ember-CLI Mocha. Only three lines to switch out your testing framework.

Back a year ago it would take two or three hours to get the testing framework set up, and you have to do it in every single app. Now, it takes you anywhere from zero seconds if you're using QUnit to about a minute if you're using Ember-CLI Mocha. This is a crazy amount of abstraction.

So you have those, and some are even easier— you just type in one line, the install, and it does everything for you.
These are 10 things that Ember-CLI does for you that you don't have to think about. It just does it with these two lines. Let's move on to the actual framework.


Ember itself does these nine things as well as several others. There's a lot that Ember does for you.

Separation of Concerns

The first is separation of concerns, once again you don't want your code base looking like a Jackson Pollock painting— or the more common term, spaghetti code.
Everything has a job to do and we separate it based on what that job is. In Ember we separate it into routes and controllers and components and things like that. This works together with the file structure to help you know where you should put something and where someone else in the past has put something, as well as how different parts the app talk to each other.

Object System

Ember also gives you an Object System. JavaScript doesn't have an object system— it has something somewhat similar called Prototypes. This is a source of a lot of confusion and I want to convince you that no one understands prototypes.

As evidence I present the Amazon test. The Amazon test is when you look up two different terms to see what's available. For Object Oriented Programming there were 26,000 results. Many of those books were up to date and written by top authors. There's a deep literature on how to write good object oriented software.

Whereas with prototypes there were 787 results, the third listing is from 1999, the fourth listing is a shoe (I’m not making this up), and then the first and second listings are titled 'You don't know JavaScript.’ So that leads me to believe that no one understands prototypes.

Fortunately Ember gives you Ember.Object with classes, inheritance, and mixins, all the things that you love from a typical object system. This specific Object System is inspired by the Ruby Object System. No matter what you think about dynamic typing or the speed at which Ruby runs… It has a really good object system, and Ember was wise to copy it.

Routes (and a Working Back Button)

Ember gives you Routes.

This may not seem like a big deal to people who are use to writing sever side applications. Because your routes just work, you ask for something and the user gets it back then they can send that something to their friends.

Recently there's been something called Single Page Applications and they have broken the web. That's because single page applications don't respect the URL. They stay at one URL while doing all these crazy things and then, if you refresh the page, it suddenly looks very different than where you were. You might lose all your work.

Even worse— if you hit the back button, you're expecting to go back one step, but it takes you back 50. That's really bad experience.

Fortunately Ember helps you with that, with almost no work, no extra work. You get a URL, you get a working back button, you get all the wonderful things that you have in a server side up but with the smoothness of a frontend application.


Ember gives you built in observers, this may not big news since this is one of the things that has been in the JavaScript ecosystem for awhile— even backbone has observers.
The basics are you can look at a property and when it changes you trigger something else. Ember just happens to bake them in and make them easier to use.

Computed Properties

Ember also gives you computed properties, which is something that is not common in web apps.

The fancy term for computed properties is functional reactive programming. The less fancy term for it is “that thing you do in Excel”. That thing where you have that one cell that calculates everything and you write an equation in that cell. Then whenever you change one of the cells that it's watching, it changes the result, it computes the result.

Ember lets you do that but not just with numbers, it let's you do that with any property in your application and this is extremely powerful.

Components, Container, Templating System, Run Loop, and More

These are the first five things in my list. You also get isolated components that is a huge topic and it's where the web is going. It's also something that is included in most frontend frameworks now.

It gives you a container, the container is something that I didn't have to think about for the first year that I was writing in Ember. That is crazy that I could spend a year using this powerful abstraction and not even know what it was. When I needed to use it, when I needed to alter it, it was there and I could alter it.

It comes with the built in templating system with data binding so you don't have to bind your JavaScript files to your templates, Ember does that for you. This is once again something that's fairly common in frontend JavaScript frameworks.

It also gives you a run loop which helps with when things are calculating or recalculating in a very quick rate. It helps me keep things manageable. This is another thing that you don't often have to think about, it just does wonderful things for you.

And a lot more.

Outside of Ember Core

But I don't want to stay on Ember for the entire talk, I want to move on to some things that are outside of the framework, in the surrounding ecosystem.

Ember Data

Ember data is a project that wants to help obstruct a way talking to the server. You can define your models, and then once you define the model it'll keep a store of a bunch of your data that is with in the browser, so you don't have to worry about storing it on the DOM, you don't have to worry about fetching it from the server every time, it's within your JavaScript run time. That helps with keeping track of things.

It also makes things much simpler to write and much easier to understand. On the left we have the Ember data way and on the right we have the old jQuery way and you can see the Ember data way is much simpler and easier to understand.

Animations with liquid-fire

There's also a project to bring you easy animations.

It maybe surprising to people who live their lives on the web but typically when you interact with something it doesn't disappear instantaneously and then become instantaneously replaced with something else. But that's how a lot of our interactions are on the web.

A good model for how it could work is iOS. In iOS, let's say you click something. It might slide to the left, and then when you go back everything slides back to the right. It looks like the menu is of to the side of your phone.

In traditional fronteend development that's very hard to do, requires a lot of specialized code. Fortunately because of the conventions of Ember this is all you have to do: you install the Liquid-Fire add-on. Then you have a transitions.js file where each transition that you want to specify has anywhere from two to ... well, they can be longer than this if you want to get really fancy.

This is an amazingly simple interface and we can only have it because it's building on top of the route abstraction. If we didn't have routes and URLs that were standard between apps, then this would be much harder to do, but because we're able to build on that giant, because everyone is on that giant we can amazing abstractions like this.

Fastboot (server-rendered html)

We can also get fastboot. With fastboot you can render your Ember app on the server side.

What that means is a web crawler can get it from the server as if it's an older, more traditional web page. It also means that legacy users, such as lynx or IE8, can get a server generated version of the website.

In a more practical example you can get the first load of a website, and then all the JavaScript loads in while you're looking at that first screen. So you get that very quick load of an older style server-generated website, but then you get interactive of an Ember website.

We’re able to do this because of all the giants that were building on and you can install it right now. It's not completely functional yet but it's coming soon after Glimmer.

Addon Ecosystem

And there are more. There are 824 add-ons for Ember-CLI.

Some are big like the ones I just showed you, some are smaller that just have a little button or a different style of design. There are all these giants here, there are some built in, some are big, some are small.

This is a lot… of stuff that you don't have to know.

Abstraction is Bliss

Remember, almost everything that I've said in this talk are things that you would have to know a lot about if you weren't using Ember, but since you're using Ember you only have to know the small Ember API that takes care of all that for you. You're standing on top of this giant and there's a few new API's that Ember introduces and there's a giant bunch of stuff that Ember takes care of for you.

Great Power

You have a lot of power in Ember. Let me give you a demonstration.

Back 14 years ago in 2001 someone started writing Gmail. He working on it, he worked on it for three years, and by the time he was done and it was released in 2004, there was over a dozen people working on it. Some of that effort went in to creating like a spam filter and backend things like that, but a lot of it, a lot of what made Gmail so mind blowing, was the interface, which at that time was astounding.

A year ago someone tried to recreate one of those original Gmail interfaces in Ember. I'm not sure exactly how long it took them on the first go-round, but now they use it to teach a beginning Ember course that takes two days.

It used to take three years and over a dozen engineers and now it takes two days for beginners. That is a lot of power… but we don't want to use that power just to recreate the great feats of yesterday.

Do Great Things

Because we're standing on giants, we have great vision. We can see further, we can see things that other people even a few years ago never would have thought possible to have happen in a web browser. Because of the power that we have in a web browser, the tools that it gives us over native apps, we can look farther than anyone has ever looked before.
So my question is- what will you build? Thank you.

Subscribe to our mailing list