Ember addons can exist as their own independently-versioned separate projects, or as in-repo addons that live within a host app's /lib folder. There are major benefits to both of these patterns, so once we cover some common addon basics, we'll outline important differences and practical use cases for each.

Typically, when working with addons, you have two top-level folders: app and addon, each of which may contain familiar folders like components, routes, etc… . We'll connect back to our newfound knowledge of the container, loader and resolver, to understand important consequences of putting certain types of files in each tree.

Move our {{x-input}} and {{x-textarea}} components into a new in-repo addon called core-ui. Make sure your templates are not in the /app folder.

Addons are the go-to way of building up an app's asset pipeline in a modular way. We'll look at the different places that we can get access to important Broccoli trees, and cover some important distinctions between being consumed in apps vs other addons vs engines.

Engines are a powerful new capability, similar in concept to the idea of Rails engines, for embedding a sub-application into a host app. This is a departure from non-engine addons, in that the engine has its own registry & container, can have its own initializers, services, etc…

We've already embedded a route-less engine into a view, so let's take things to the next level and mount a routed engine in our router. We'll need to introduce a few new concepts relating to how engines share information with the host app, and pay special attention to the way we create {{link-to}} components that cross the host/engine boundary.

Beyond encapsulation, one of the biggest benefits that come along with engines is that it frees us from having to pile our entire app into one big set of static assets, to be downloaded as the user first enters. Lazy engines allow chunks of assets to be downloaded on an as-needed basis, as a user crosses an engine boundary.

Although this adds a little extra complexity to our apps, the performance payoff can be huge, particularly if infrequently-used sections of your app are particularly heavy in terms of dependencies and application code.

We'll take a step back and recap everything we've learned so far, putting in the broader context of being able to build out things quickly, robustly and sustainably with Ember.js.