Staring last year, Ember is calling once a year for input on what people want to see being worked on in the framework to form their roadmap. The responses from last year were amazing with so much constructive input and ideas. Reading them was a fantastic learning experience to gain insights into all those creative like-minded people that form the Ember community.

My wishes for Ember (in 2019) is to slim down the framework is to throw old ballast over board to improve learning, developer ergonomics and align more with the javascript ecosystem.

1) Reduce Mental Burden

Ember is often connotated with a steep learning curve and to some extent is. One reason is the old ballast it’s carrying around from the early days. By throwing it over board, Ember will not only loose pounds but also reduce the complexity and simplify itself to make a step towards new Ember developers. Lots of this complexity is because of applied conventions, that require “hidden” knowledge of several framework functionalities (that even trap me as an experience ember developer). I wish those things will be dropped or replaced with modern approaches that are more consistent with the rest of the javascript ecosystem and I list some of those. Overall the goal should be to have no more magic!

Align with JavaScript

For mostly historic reasons, Ember is providing developers with superpowers onto plain javascript objects (e.g. array.firstObject or array.findBy but also the whole EmberObject model) and we (un)intentionally use them. It was one of my pain points since the beginning, that Ember (had to) diverge from javascript, which is nowadays very hard to understand, especially for new Ember developers.

Things are already looking good here with using native classes and new addons have the ember-disable-prototype-extensions installed already helps a lot. Ultimatively this means dropping the EmberObject model at all, which way ember will loose a lot of pounds (although we know this will take a little while).
This is less of a framework mission but more of a community goal to make our code legacy-free. Maybe Emberobserver and/or ember-cli can help out here with indicators to legacy code.

Drop Initializers: Zero config, maximum magic!

Very often I am wondering where things come into my code. What’s that service about? Why do I even have this service? and what’s up with my ApplicationRoute not behaving the way I expect it to be?

The answer most often is initializers: Zero config, maximum magic!
Sometimes installing an addon is like installing an app on your mobile phone, where the app assumes it is the most important and most used app and spams the user with all the notifications it has. For Ember addons, the notifications are initializers. The addon hooks into everything possible to help out with whatever it offers, like clippy from ms word.
Yes I do love your addon, that’s why I installed it but please let me configure it the way I need it for my current app.

For that drop initializers, give apps a better way to configure their runtime and also support ember-cli-addon-docs, so it can provide a slot to document the (runtime) configuration of an addon in a somewhat standardized way.

Routing + Pages vs. Route + Controller

Ember shall be a component first framework. The Octane edition finally enables glimmer components for Ember itself, which are a blessing to use. Unfortunately routes and controller withstand this elegant way of developing. They add a second concept (next to components) inside the framework that a new Ember developer has to learn, with all its rules conventions that apply here. The mechanics are more in the direction orthogonal to what components are (A routes model is available in the respective template but for all other properties you need a controller first o_O). Handling query params is a nightmare on its own, that actually nobody enjoys doing.

My idea is to drop controllers and routes (not routing!) and replace them with something we already know and love. A special kind of component: A Page. A page is extending a glimmer component (and by that inheriting all the things we know and love) with some special sauce on top to handle (query) params and transitioning.

Ember would loose more pounds by dropping not only routes and controllers but all things that come with them that probably not many people are using, e.g. loading and error states for routes (I used them exactly once!). Also no more model hooks, instead use transitioning hooks to load your data imperatively (e.g. with a task) and assign it to a property or declaratively with the help of data provider components. Each approach can yield their state appropriately.

The most simple page is a template-only page with {{yield}}as its contents.

Recycling an already learned concept also improves the learning journey. For a developer already familiar with how to build components, it’s a thin layer to learn on top to use pages.

2) Developer Ergonomics: Make things Explicit

Octane already made a huge leap forward here, stripping down the component functionality to its bare minimum. One of the missing pieces – that is currently worked on – is explicitely importing parts of Ember. Things that resemble around topics like template imports and SFC. At the moment, there are heavy conventions and the Ember resolver swings his magic wand to find the right files. With MU the complexity increased steeply and was one of the factors to led to burrow this project. Instead the idea is to leverage javascript language features and use all the exisiting tooling it is already there – I’m looking forward to this.

This is already covered very well by more #emberjs2019 posts. I like to address two more topics from my point of view.

Application Configuration

Imagine routes and controllers are gone for good, there needs to be a replacement for the famous ApplicationRoute.beforeModel() hook to handle the programmatic runtime configuration for your applications. I wouldn’t like to see it baked in to whatever the route/controller replacements are, because it semantically doesn’t belong there. Instead when I install an addon I consult their readme/documentation find the required code snippet to “boot” this addon and copypaste it into my configuration file. This will move the magic from initializers into the spot where I can control and tailor it to the needs of my application.

File Layout

I was one of the early adopters to MU. I liked it most for the file system structure it provided. It had nice spots to put your stuff into and Presto Sego (nullvoxpopuli) was totally right to call it a general and flexible project structure that works for all projects in any ecosystem. I see the most benefits in the spots it provided for various types of things and by offering a clean structure on my file system. Moving back this weekend to a classic layout, I dropped some tears for the clarity I lost with that.

Second was local-lookup or having components for specific routes not cluttering the “global namespace”. Things like that will be possible with template imports/SFC mentioned above. From my experience I definitely see value in having that in the future again.

My hopes for a future layout are the clarity it will bring along with desired spots for the various things you can have in an Ember application. I also hope there will be a community driven convention to have a shared understanding about Ember apps – which is one of its current strengths as any Ember developer can jump to a new project and feel home immediately. It’s a strong asset I wish to continue to have.

3) Embroider it all up

Embroider will undoubtly be one of the focus projects for Ember in 2019 as it will embed Ember into the javascript ecosystem to support all the mentioned topics. I like to see what the performance improvements will be with things like tree-shaking or lazy loading parts of your application and me doing nothing for it. I’m looking forward for this project to land as it will also enable new things to happen, e.g. it will pave the path to improve ember-cli related developer ergonomics, which I’m interessted to look into once it’s time to do that.

Ember up your Way

I hope, with all the reduced complexity, the nice side-effects will be that Ember will loose a lot of pounds. Making it to start slim projects and “ember up your way” to what you need. An imaginery process could look like this:

1. A glimmer application: The bare view layer.
2. An Ember application: Component-Service Framework.
3. Add pages and install routing.
4. Add a data layer to contact APIs.

Ember in 2018 was a very engaging journey with a very positive momentum that I’d like to continue for 2019 to generate more uplift amongst the whole javascript community.

– gossi