Emphasize the role of Ember addons more!

As you may know, the core team made a Call for Blog Posts some time ago. I was thinking for several days, what can be done or expressed better in our community? I want to bring Ember Addons on the table. This concept is so deeply embedded in the community that nobody inside seeks to explain. Meanwhile, for the people outside of Ember, the concept is not clear.

I read many #EmberJS2018 posts written by many community influencers. Those that came to my mind immediately are “Be loud and be ready — my hopes for Ember.js in 2018” by Jen Weber and EmberJS 2018: Ember as a Component-Service Framework by Christopher Garrett. It’s inspiring. Here are my two cents into the movement.

“What is an addon?”

I was asked exactly this question and couldn’t find any meaningful 1–2 page article that nicely explains it.

Try to imagine a person who never worked with Ember and doesn’t know about Ember concepts. What is their first reaction? Of course, google it. What will be in the results?

First, the Ember Addons site, which doesn’t have any explanation, just lists addons.

Second, the doc section for ember-cli about extending. Sounds reasonable, but contains only these words:

Addons make it possible to easily share common code between applications. However, if an addon only covers a very project specific use-case, an In-Repo-Addon could be considered instead.

Nobody can grasp the idea of addons from this sentence.

The closest to the point is Tips for writing Ember Addons
But its the second thing you need to read about Addons. The first must explain the concept to the neophytes. Do we have such an article? Not yet.

So, what is an addon?

I will try to explain what an Addon is and why they became central to the community.

First of all, technically, an Addon is a stand-alone npm package. But it's not "just" an npm package, since it was created in a special way with theember-cliapplication. Because Ember.js is an opinionated framework, applications have a predefined strict folder structure rules. Addons exploit this structure by adding their files into the application. Its a rough explanation - addons can do more. But mostly what they do is adding files into the consuming application.

Addons have a set of specialities:

• A developer places classes into addon folder, but not in app like in a normal app.
• ember-cli is able to resolve addons file structure and correctly integrate files into the consuming application. When an Ember app will start it will treat addons files like its own.
• Addons can do other things, like adding some dependencies into the consuming application during the installation step.
• Typically, the name of the addon in npm starts with ember-or ember-cli but it’s not mandatory.
• Normally, you install an addon into you app via command npm install ember-addon-name --save-dev(same as ember install ember-addon-name through ember-cli).
• An addon has a dummy application inside for testing purposes which is a 100% Ember application. Many use this app for documentation purposes.

What can be extracted into the addon? Almost anything. But usually:

• One complex component that can be reused in several applications, e.g. a table component or a component likeember-power-select
• Styles (with the same rationale)
• A component library. Like ember-bootsrap or ember-paper(addon for material design)
• A wrapper for third party libraries to integrate them seamlessly into Ember apps, e.g. ember-qunit, ember-momentor ember-d3.
• Ember classes, like services, helpers, etc
• Additional development or testing tools. Look at the remarkable ember-cli-mirage addon as an example.
• Explore EmberObserver.com for others. Addons that have score 10 are very largely in use.

What else can we say about addons?

Addons are the cornerstone of DRY and DRW.

(DRW — Don’t reinvent the wheel)

I guess you have already understood that the main benefit of creating and using addons is reuse of code. And it appeared that having a strictly defined folder structure is not only a point of criticism from the followers of less rigid frameworks, but it actually enables the gorgeous world of reusable stuff. You build it for your own application, but all others can use it instantly. The opposite is also true ;). Check and mate!

Addons allow several teams effectively co-own one app.

Addons enable effective cooperative work for several teams. For instance, one team is responsible for the division of the app into separate parts and for later integration of these parts back into the big application. Then each supportive team works on different parts, isolated in addons. As a bonus, with Ember your developers can move from one team to another without loss of productivity.

Addons create clusters and community.

This point can be a separate article, maybe I will write it later, now let me just mention some addons:

• ember-power-select
• ember-cli-mirage
• liquid-fire(this one was created before start with ember-convention!!!)

Popular addons attract people who ask, make proposals, open issues and PRs. And because the framework is stable, addons are also stable. Gradually, they constitute community clusters around themselves. That is great, because our community is structured. We all know and use same addons, have same issues, solve same problems and understand each other.

Addons make their authors famous.

Just some names. Miguel Camba, Sam Salikoff, Edward Faulkner, Alex Matchneer. They got famous after they created super-successful addons (maybe Alex is an exception, since he has been already well known inside of community before ember-concurrency)

Ok, Addons are important. What we need to do?

Now, we really understand that addons actually are one of the crucial success factors for Ember. But how can we care about them more? Definitely, a clear explanation of the concept for people outside of Ember community is an obvious idea. I wrote something basic and probably silly but hope it will help our learning team to come up with some better ideas about introductory documentation for addons.

What else? I wish I could answer by myself. But I can’t do this without your help, dear Ember community. Hopefully, your feedback will help to find the detailed answers. For the appetizer here are some high level points:

• Typical scenarios of breaking application into addons. What is good to extract into addon and what should stay inside of the application.
• How an addon injects into the application. appfolder, initializers, index.js file, etc.
• The dummy application.
• How to test addon and how to document it.
• How to explore the addon landscape. Emberobserver.com, emberaddons.com, etc
• You name it!

Thanks for your attention. I’m looking forward to your comments.

PS. Sorry for language mistakes, I’m not even a canadian)