I’ve really enjoyed reading the varied blog posts responding to the core team’s call. I’m the past the deadline, but better late then never!

For background, I have been working with Ember since it was under early development as Sproutcore 2.0. Ember.js powers a SaaS company I co-founded, Yapp, and we funded our business for a couple of years doing Ember consulting under the Yapp Labs moniker. We’re full-time on product now, and my engineering team at Yapp (currently 3 people) maintains around 6 Ember apps. I help maintain a bunch of popular addons, including ember-cli-deploy, ember-modal-dialog, ember-wormhole, ember-tether, and more. Two former Yappers are on the Ember core team (hi Kris, hi Stef!). I started the Ember NYC meetup in 2012 and continue to co-organize it today.

So it’s fair to say that I am “all in” on Ember. Being part of the growth and evolution of Ember and its community has been one of most rewarding aspects of my career in software.

I’m going to leave the marketing and evangelism themes to other posts. They are important, but not my area of focus.

Instead, I’m going to write this #EmberJS2018 post about the pragmatic things I think the core teams and community could focus on to make day-to-day development more efficient, effective, and productive.

First some brief words on what is awesome, and then some ideas and whining about what needs improvement…

What’s good

A few of the things that I love about working with Ember:

• the component architecture
• the testing experience (especially the new style, paired with qunit-dom and ember-test-selectors!)
• pod-style colocation of JS/HBS/SCSS
• the addon ecosystem
• the addon architecture, and what you can do with nested addons to power internal code-sharing
• release train and upgrade paths have been awesome since 2.0. I have 7 year-old apps that have been upgraded to modern versions of Ember without pain (since 2.0 at least!)
• the deployment experience, powered by the ember-cli-deploy & plugins
• adoption of new standards to great benefit: async/await in tests and yield in ember-concurrency tasks are good examples
• styleguide-driven development with ember-freestyle is a joy
• the people! I can’t express the depth of my gratitude for the brilliant, kind and generous people I’ve met, befriended and collaborated with in this community.

With that lovefest out of the way, on to ideas and criticism.

Allow declaring the properties a component accepts

We’ve been using ember-prop-types to declare what passed properties our components accept. They can be really helpful in failing fast when a refactoring step is missed.

Not using this is like writing every function to accept a `params` hash — a developer has to read the code to figure out what keys are allowed to be passed in. We wouldn’t accept this practice for our Javascript code — why accept it for our components?

ember-prop-types is under-maintained and has some weird edge cases that make it underperform its potential. A higher quality version of this should maintained, endorsed and documented.

There may ways that Typescript can serve this purpose or enhance the developer experience in this area as well.

Error messages & debugging experiences need to be better

Test failures and runtime errors all too often do not log the initial error clearly and instead show a second or third-order effect instead. A community project could be initiated to catalog the most commonly thrown errors and make the top 50 have mind-blowingly awesome messages and debug experiences.

I have been writing Ember apps for since Day 1, and I still find myself in situations where there I am face failures that take me a few minutes to even understand what the actual failure message is. I shudder to think how new developers must experience this.

ember-cli build & rebuild times and tooling

Ember CLI has come a long way in build speeds. And yet, as projects grow, I have found that they become a real pain point. Worse, when a project is feeling slow, it is too hard for a developer to understand how to make it faster, or even what the tradeoffs are. For example, it seems from our ember-cli output that something related to source maps are making many of our builds painfully slow, but I don’t know what to do about it.

Live reload / hot reload

We should make sure live-reload is as awesome of an experience as possible, including supporting hot reloading of modules. I played with Toran Billups’s ember-cli-hot-loader and while it is a cool prototype, it left me convinced that this feature needs tight integration into ember and ember-cli to be done right. We spend a lot of time waiting for rebuild / reload cycles, and I don’t think we are alone.

Named Slots/Blocks

The power of component composition and contextual components are hampered by the lack of a “slots” story. A lot of work has gone into iterations of RFCs including this merged one and is listed on the Status Board as “In Implementation”, but I’m not sure what stage.

I predict that landing this feature in Ember will make us wonder how we lived without it for so long.

Stronger CSS conventions

When looking at a Ember codebase, I usually know what to expect from components, routes, and services — what will be in them, and how they will be organized. CSS has no such consistency across Ember apps, in my experience. I think there’s an opportunity here.

Contrary to the functional CSS approach recently championed by Sam & Ryan from EmberMap, my team has had excellent experience with colocating `style.scss` files with our components, with isolation gained from the SUIT CSS naming conventions. (The SUIT conventions are largely a prettier BEM.)

I don’t feel strongly about the specific naming conventions, but I do think that isolation and maintainability should be the key criteria we’re looking for. In my opinion, the separation of concerns you get from a separate stylesheet outweighs the benefits of assembling class names in your HBS files. You can embrace a limited CSS vocabulary through mixins if needed.

The larger point on CSS in Ember apps, though, is this: let’s get to the point where we can end the bikeshedding and have a standard way of styling our apps that we can start building experience and abstractions on. (Maybe CSS Blocks can be that path? I don’t know enough about it yet.)

Ember Native

As someone who maintains a lot of Android and iOS native code alongside several Ember apps, I look longingly at React Native. I would prefer the conceptual consistency and code sharing possibilities of “Ember Native” instead.

If someone who understands the right Glimmer hooks did a basic implementation, I think a sub-community will rise to fill out the project.

This suggestion feels somewhat heretical given the web evangelism and native-trashing of the EmberConf keynotes. I sympathize with this, but hey, I promised pragmatism.

Fin

If you read this far, I you came away with this some good topics to think about in the above, or at least that you enjoyed reading it as much as I enjoyed writing it.

Viva la Ember!