Ember.js in 2018

This will be a short post because I feel that most/all of my points have already been made by other people.

I started working with Ember.js around 3 years ago and I have been annoyed by it ever since. In fact I was so annoyed by a few things that I started contributing to the project and at some point was invited to be a member of the Ember CLI team. At the end of the day Ember.js is still a great project and investing time to fix the most annoying things payed off not just for me, but also for the rest of the community.

One notable example of this was QUnit and how testing in Ember looked like until a few months ago. Writing acceptance or integration tests with QUnit made me mad because the APIs seemed so foreign and verbose. I was very happy to learn that Mocha could also be used with Ember.js and that it allowed me to write nested test suites, each with their own setup and teardown code. Then came simplabs and with it the requirement to use QUnit in some of our client apps. I was going mad again… at least until I figured out how to improve the situation.

Last year I’ve started sketching out a new testing API for ember-mocha, which was later adopted by ember-qunit too (Thanks Rob!). That meant async/await instead of implicit async code and using native QUnit APIs instead of having a dedicated moduleFor() function for each type of test. I also took over maintenance of ember-test-selectors which made our tests much less brittle and towards the end of the year I started working on qunit-dom which makes our assertions much more readable and will be included by default in Ember project starting with the next Ember CLI release. I am now finally at a point where I enjoy writing tests. :)

The point of this little anecdote: if you’re annoyed by something try your best to improve the situation for yourself and everyone around you. It will pay off!

Finally a short list of things that are currently annoying me about Ember.js and that I will hopefully find time to help solve in the next months:

• Code Splitting
  This has already been mentioned by many people. When I’m writing an application and some subroute needs to include a Leaflet map I shouldn’t need to ship the Leaflet code to all the users that are not visiting the route. This stuff needs to become a lot easier and I’m really happy that Kelly Selden and Alex Navasardyan have started tackling the issue.
• Importing npm modules
  This has already gotten a lot better. A few months ago we made it possible for app.import() to import files from the node_modules folder, which enabled us to throw away a lot of old bower dependencies. ember-cli-cjs-transform makes this even better by supporting CommonJS and ES6, and automatically bundling up all the necessary dependencies. Ultimately the work around Code Splitting will most likely make all of this unnecessary and “just import the thing” should work out of the box.
• testem
  Ember CLI by default is using testem to run tests in all the configured browsers. That works mostly well, but I’m far from enjoying their interactive CLI mode. I had already looked into using Jest for test reporting using a custom Jest runner, but due to their (Jest) architecture this seems nearly impossible without major refactorings and new APIs.

I’m trying hard right now to think of other things to add to the list and I guess that’s a good sign. Things like marketing and documentation can always be improved too, but overall I’m pretty happy about using Ember.js in 2018, even though many twitterers seem to disagree with that opinion 🤷‍.

Let me close by reiterating: if you’re annoyed, please help yourself and others to improve the situation, whether it is contributing code and documentation or helping with marketing by giving talks and helping others develop their talks. Ember.js lives from its community and you’re part of it!