Ember in 2018, getting ready for the next major release

This post is in response to the Ember's 2018 Roadmap: A Call for Blog Posts.

Here are my thoughts about what Ember should focus on for the remaining of the year. The community has written many great posts already, while I agree with many of them, I wanted to express my thoughts. You will also see many similar points here from other posts, that's because I want to enforce the importance of them to me and the community.

Deliver the promised land

Many other posts talked about this topic, but I wanted to highlight the most important features that I have been waiting. I firmly believe that Ember needs to deliver all the great new features that are currently in flight before taking more to its plate.

Module Unification

The implementation is almost complete, and it will have a significant impact on how we develop Ember applications. It will make apps feel more modern and organized. Some RFCs need to be merged for us to be able to get to the finish line, so we should get these moving.

Glimmer components

Glimmer components are straightforward to use and have a small API surface; they are fast and modern. Unfortunately, we haven't seen much movement in that area since the creation of the Quest issue.

<AngleBracket /> Component invocation

This is another vast improvement in the ergonomics of how we use components. Recently, the initial work to support angle brackets invocation has started, and that's amazing. We need to get it to the finish line.

@tracked decorator

I have created a Glimmer.js app in which I used the tracked decorator, and it was great. The programming model is more straightforward and very intuitive to use. Tracked properties have landed in Ember behind a feature flag including Autotrack. I believe what's missing to be enabled by default is the integration with EmberOjbect.

Packager

The Ember CLI team has been working a lot to deliver the Packager. The Packager will allow us to experiment with other bundlers as Webpack or Rollup.js. The Ember community desperately needs more experimentation in this area.

Controllers

Let's be honest here; controllers is one of the roughest parts of Ember. I personally only reach for a controller when I'm working with Query Params. Even though I need to define Query Params on the route and in the controller itself, why can't we have only one place for that?

A long time ago we had the proposal for routable components, everybody was very excited about it, but that didn't work out. I believe we should revisit how we work with routes, controllers, and query params.

The article by Chris Garrett on EmberJS 2018: Ember as a Component-Service Framework seems very attractive to me, but one of the areas that would make that approach even better is to get rid of controllers and create a service to manage query params. There has been a discussion about the future of routes in Ember on Discuss that showed some approaches that we could take, but at this point, it is just speculation. If you have thoughts on this subject, feel free to step into the conversation and give your feedback.

Ember CLI

Ember CLI is such a fantastic part of the Ember ecosystem, but I believe it needs to be revamped.

Please, let us just NPM import packages into our projects. It is very annoying to keep creating add-ons just for shims and do a Broccoli Funnel to import packages to our Ember apps. I know that the Packager work will allow us to get this, but we are not there yet, and we have been waiting for this feature for ages.

Other articles have highlighted the importance of having Code splitting, Tree Shaking and such. I agree, let's get it to every Ember app.

Also, let's play better with the rest of the JS ecosystem. I enjoy the stability that Ember CLI brings to our community. The easy install of an addon that plugs into our build pipeline and makes everything "Just Work," is impressive. However, there has been such a great deal of innovation in Webpack community that it feels we are way behind in that space. I don't know if Packager is the thing that will allow us to integrate well with other bundlers like Webpack and get all the significant innovations that are happening there, but we must let people innovate in that space and keep the stability that Ember CLI brings to us today.

Data & Ember Data

Ember Data is a compelling project, but it can get complicated for beginners.

I think we should remove Ember Data from the default blueprint and remove it from the tutorial. I have the impression people that are trying out Ember for the first time don't see the value that Ember Data brings to them. Also, people might not realize they don't need Ember Data, and so they get frustrated because their API is not compliant with JSON:API, therefore people can feel that "Ember is not for me." Getting started with a new framework is a huge step, and at the same time learn about adapters and serializers can be quite tricky.

Ember should also encourage the use of other data patterns besides Ember Data. Maybe we could have a section in the guides to talk about different data patterns that people might want to use with Ember. Perhaps we should have a tutorial about using Redux or something else. Maybe we should have our own "Vuex."

Errors and stack traces

Sometimes is very difficult to debug errors in Ember because we don't get a useful stack trace. Errors that get thrown within the run loop or internally in Ember don't get a useful stack trace. Usually, the stack trace given is just a bunch of Backburner and Ember.onerror references. I would love to see this fixed.

There is an issue where errors that Ember CLI throws get lost once the page gets refreshed. For example, template compiler errors. We should get these fixed; errors should be persisted and not dropped if the page gets updated. Wrong module imports should also be a build error, not just a console log in the browser.

Also, errors and test failures from QUnit should contain the location of the test file (in disk). It is very disappointing to see the error message leading to the vendor file without much information where the test is located.

Tools

Ember should provide developer tools as first-class citizen. Tools like language servers are great for DX. There is work happening on an Ember Language Server implementation, but I think this should get treated as an essential part of the framework. Another tool Ember should have, an integration with Handlebar templates and Prettier.

Rebranding

Ember needs to go through a rebranding phase. And I mean in almost all areas. We desperately need a new website with new content and modern design. We need to sell Ember better, to show our values as a framework and as a community. We need to show that Ember is current and remove the image that Ember is behind other frameworks. We must attract new users to Ember if we want to stay around.

Some people have talked about removing Tomster and Zoe, I don't necessarily agree with that, but I think we should make our image more modern. Should we maybe rework a bit our color palette, fonts, etc.?

Creating a Marketing team seems to be a natural thing for core team todo. We need to start fixing some these problems.

It would be awesome to have a page describing "Why Ember" with a section focused only on selling Ember to stakeholders, another part selling to developers, and maybe something for designers as well.

Getting the "buy-in" to a new framework is not about one person or a few developers, but instead is about the whole organization. The CEO wants to make sure we choose the right technology to be able to hire and attract great engineers to the company. Designers want to make sure we have tools to work better with them, tools like integration with a component library and Sketch. Developers want to have great tools for development and debugging while having a great time working with the technology.

For Ember to stay relevant, we must attract new developers and teams to use it. It won't matter if we have the greatest tech if we can't draw new people and make them excited to use Ember.

The next major release

Once we get all the features from the promised land shipped, I think Ember will get well positioned for the future. So for the next major release, Ember should enable many of the new features by default.

  • Use ES classes, decorators and all the new JS features by default.
  • Module Unification by default.
  • Glimmer components by default.
  • Tracked properties by default.
  • No more controllers.
  • Angle Brackets by default.
  • No jQuery by default.
  • Broken up Ember packages. (AKA: install your way to Ember)
  • Code splitting by default.
  • Tree Shaking by default.
  • Playing better with the rest of the JS community.

If we put all these features together, Ember will fell much, much more modern compared to today's Ember. It will be easier to learn; it will have a smaller API surface and much more. I'm very much looking forward to the day where everything above is on by default.

TL;DR

Ember must deliver the promised land, all the features that are currently work in progress should get finished and shipped. Better integration of Ember CLI and the rest of JS ecosystem. Just NPM import a package should work. Data patterns without Ember Data. Better errors and stack traces. Take developer tools seriously and make them first-class citizen part of the Ember project. Rebrand, create a new and modern website. Make all the great new features the default in the next major release.