Quo Vadis, EmberJS? My EmberJS wishlist for 2018

What can be changed in Ember to make its users even more content when working with it? In this short publication, I will try to present a few ideas, which in 2018 could help the development (and further growth) of this tool. The article is an answer to the #EmberJS2018 initiative.

1. Smaller build size

Removing jQuery and other big, potentially optional dependencies from Ember is definitely something that should be carried on. Fewer dependencies equal possibly easier debugging. Tree-shaking in all the main packages will also shrink the framework.

2. Strong-typing

More and more people look for more advanced methods of writing frontend. TypeScript seems to be the next big thing in our world. I really enjoy Chris Krycho’s work, who is giving TypeScript a push forward in our ecosystem — maybe it would be worth to direct power to his project to speed up typing also in templates.

3. Reduced learning curve

Series of screencast about app development with various use-cases, available from Ember’s home page should encourage new users to learn our tool. This is why I am all for any kind of simplifications of the tool because it will make learning and popularization of this technology much easier.

4. Refreshed website

Let’s not be afraid of this word — archaic. Ember’s website left its good days way behind. It should not be a surprise that it is the first place where a new user goes to when ‘researching’ Ember. A simple and interactive demo, together with a more modern design could greatly improve Ember’s marketing strategies. Additionally, posting real-life examples in the documentation (not only snippets of the code but also showing it ‘in action’) would be an awesome improvement for newbies.

5. An add-on market

Yes, we have Ember Observer, but it is not well-promoted on the home page. Maybe its integration in the shape of an add-on search engine directly on Ember’s home page is worth considering — an self-standing add-on market?

6. Further improvements of the error messages

For many people it is still a major obstacle when working with Ember — especially in bigger projects — the possibility to even further configure the stack trace and the level where those type of errors could be ‘caught’ — or mapping of common errors for something more meaningful for the less experienced developers would definitely help and made it more beginner-friendly.

7. Routable components

This topic comes and goes like a boomerang and despite the fact that it was, as for now, abandoned, it is worth to consider going back to it — we have a router service, which API allows moving many things from the router — maybe soon we will be able to work with the query params through a public API — it seems to me to be naturally the next step in order to unify and migrate to the components that are routable. What is more, it could make migration from other ecosystems (eg. React) to Ember easier, thanks to the reduced complexity and getting closer to other ecosystems.

8. Focus on things that can attract businesses as well as developers

In order to maintain the interest of our technology, a better exposition of companies using Ember, and why they do so, is valuable. Nice case studies / short films / personal interviews with people that use this technology will definitely help to build trust for it.

9. Stick with QUnit

People often have problems choosing the test framework. Some choose Mocha, others QUnit — for newbies Ember Ninja can be a bit misleading and hindering the test writing process. It is better to clearly define one solution and stick to it in order to avoid future problems during application / add-ons development.

10. More testing examples

We need more examples of how to test components and behaviours in the expanded guide for testing (which will be easily accessible for newcomers).

Summary

We are currently living in times where Ember’s ecosystem reached high stability. Because of dynamics in the industry, I really like the concept of fast implementation of changes, for example through feature flags. If we do things right and we find imitators (for example, in ReactJS something similar to Ember’s RFC was implemented) — paving the way for new trails is worth continuing. Standing out will not hurt us and additionally, it will motivate others to join the Ember community and actively contribute.

I cannot wait for all the new things we will introduce to Ember in 2018.

Live long and prosper

Something extra

PS. feel free to post your own #TomsterOnTour tweets like this one:

Bye :)