Learning Ember: The Easier Way

We Help Your Agency Reach New Heights

Switch from multiple tools and spreadsheets to one scalable agency management system.

A couple of months ago, there was a huge shift in my work-life. Or so I thought.

Instead of working in Vue or React, I had to learn Ember for my new frontend position at Productive. I was sure I would have needed quite some time to get used to it. Up until a few months back, I didn’t know what was going on in the Ember ecosystem. Although this didn’t scare me, I felt like it would be a hefty challenge because I wasn’t sure what I was getting myself into.

Turns out, it’s really not that different from the frameworks I already know. All of the usual things you’d expect are there. Things like store management, component slots, dependency injection and much more. And they were a bit easier to use since it all came out of the box! 

You don’t have to spend a lot of time deciding between libraries, patterns or technologies because a number of them are already there when you just install Ember. It does have some nuances, pitfalls and you still have to choose between some libraries (UI libraries, I’m looking at you), but I haven’t worked with a framework where you didn’t have to worry about anything. After I took all this in, the hefty challenge didn’t seem so bad anymore. Now, this was just a matter of getting used to the framework.

As I’ve started to learn about Ember on a deeper level, a lot of the concepts were familiar to me. Some were described exactly as you’d expected them, some were named differently and some used a different terminology.

But since Ember has such a long history (for a Javascript framework, at least), there are some terms I wasn’t aware of. That’s why I started to write down anything that I wanted to learn more about. This included libraries, phrases, patterns and technologies. I was sure this would help me in the long run, so I’m sharing it with anyone who’s just starting out with Ember.

This is especially helpful if the codebase you’re working on has a couple of years under its belt. It pays off knowing how and why things were done so you don’t accidentally break a functionality when refactoring.

I’ve talked long enough, so here’s the list!

Embroider

A modern, full-featured build system

Some build features it is supposed to provide:

Reduced build and reload times

Tree shaking for Ember related modules, components, etc.

Support for arbitrary code splitting

You can opt-in to use it, but will be used in the future

Learn more about it:

Glimmer

DOM rendering engine

Architected like a virtual machine (uses Glimmer VM)

Can coexist with classic components

Builds a “live” DOM from Handlebars templates and cheaply updates after data changes

Learn more about it:

Classic components

Older-style components that do not use native classes

Glimmer components are preferred nowadays

Learn more about it:

Handlebars

A templating language not specific to Ember

Used in Ember to define component templates

A superset of Mustache templates

Adds some functionalities to make writing templates easier

Learn more about it:

Mustache

Can be used to template anything, not just HTML

Called logic-less because it has no if statements, else clauses or for loops

Learn more about it:

Broccoli

An asset pipeline

Used for converting ES6 to ES5, SCSS to CSS, etc.

Supports constant-time rebuilds

Came as a replacement for Grunt

Learn more about it:

“Data down, actions up”

Represents a unidirectional flow of data

Passing data to a child component or subroute

The child component receives the actions that modify the given data

Helps with the separation of concerns

Avoids complex data loops

Not specifically related to Ember, but mentioned in the docs a lot

Learn more about it:

Ember helpers

Javascript functions that can be called from the template

Ember offers some helpers out of the box, like:

Let

Get

Concat

Learn more about it:

Ember engines

A specific type of Ember addon

Allows multiple logical applications to be composed into a single application from the user’s perspective

Requires a host application since they don’t boot themselves

Helpful when trying to separate the different areas of a single application

Can be used in the host repository or in a entirely different repository

Learn more about it:

Ember test helpers

DOM and other testing helpers that are not automatically included when Ember is installed

Learn more about it:

Ember Fastboot

Ember SSR

Does not require codebase changes for it to work

Learn more about it:

Ember modifiers

A way to interact with the DOM in Ember (instead of manual interaction)

Some modifiers come out of the box, but you can also write custom ones

Learn more about it:

Autotracking

Ember’s reactivity model

Decides what to render and when

Learn more about it:

Qunit

A testing framework

It was used in jQuery, but was extracted as a separate project

Not specific to Ember, but is used in Ember by default

Learn more about it:

Ember CLI

The official way to create, build, test and serve Ember projects

Other frameworks have their own versions, as well

Learn more about it:

Octane

The current edition of Ember released in December 2019

Introduced a lot of new concepts and newer ways of developing

Glimmer components

Modifiers

Learn more about it:

Polaris

Ember’s next edition

Will introduce more new concepts and functionalities

Learn more about it:

I’m sure some things might be missing, but this is what was the most puzzling to me. Hopefully, you’ll find some use of all these terms!

Also, I feel like it would be kind of rude not to mention the resources I used while learning Ember: (yay, more lists)!

Davor Tvoric

Frontend Engineer

Related articles