Stability without Stagnation in 2018
Today, we can try out possible future features of Ember using addons already available. Some such addons include:
- ember-fastboot
- ember-engines
- ember-cli-module-unification
- ember-decorators
- ember-cli-typescript
- ember-css-modules
- ember-glimmer-component
- ember-named-yields
The above is by no means an exhaustive list, they are just the ones I’m most aware of. Part of the reason I list them here is to get more people to try them out and to use them.
Recently, while testing out ember-cli-typescript, I noticed there was no way to scaffold a new project. If one just ran ember new and then ran ember install ember-cli-typescript, one still has quite a number of .js files and quite a bit of learning to do to figure out how to turn them into .ts files without a whole bunch of errors.
So I hope the authors of all these addons work on scaffolding and migration. When you first try out one of these addons, you want to do so in a new project, or to convert an existing project. Either way, it should be as easy as possible. ember-cli-module-unification has a great story for both migrating an existing app and setting up a new app or addon, and should be the model here.
However, I see a major problem with this: while a person regularly attending meetups and conferences or reading blogs might be aware of these addons, a person starting a new project in Ember usually isn’t. This gives a person the impression that Ember has changed little in the past year.
When you generate a project with ember new, you get a project that is almost “legacy” by standards of the wider JavaScript community. Few people ever try these addons out.
But we certainly do NOT want to just include any of these in the default ember-cli blueprint. Some of them aren’t anywhere near mature enough yet. Some of them aren’t for every project. And most of all, existing projects should not be pushed into using these addons when they use ember-cli-update.
An important question that needs to be asked is, how do we expose something like ember-fastboot to the new Ember user without including it in the default ember-cli blueprint?
One approach is that you can add a --fastboot flag if you want your project scaffolded with fastboot. This is not very discoverable, and I already don’t like it when I forget to add --yarn.
Another approach is already being used by module unification. You can set up an environment variable and have ember-cli look it up when calling ember new. I don’t think this is discoverable either.
A third option is to use the approach used by an addon I saw a while ago: ember-cli-opinionated by Jordan Hawker. When running ember new, unless a --non-interactive option is added, ask if they want to use fastboot. I personally like this solution because it strikes me as being the most discoverable. Plus it can be combined with one or the other of the above approaches for that non-interactive mode or simply to avoid one or more of the questions.
One would have to save the choice(s) made at ember-new time and use it. It would be great if ember-cli-update then looked up that choice and updated accordingly. But the unresolved question is, what if one wants to switch their choice later?
I don’t have all the answers. But I would like to see these issues addressed this year. I think this is critical to delivering the promise of “stability without stagnation” because without exposing addons like these, Ember appears stagnant, and pushing these addons onto existing projects will break the promise we make of stability.
