EmberJS in 2018: Beyond Quietly Productive

I wanted to write a post for the #EmberJS2018 initiative since it began, but never got to it, so here’s my try to catch the last train. I realize that most of what I have to say has probably been written by someone else already and some of the features I am going to mention are already in progress or even ready for us to use. I hope that it doesn’t hurt to reiterate on what I consider important and perhaps others would agree.

Ember’s “PR Problem”

Not the GitHub kind of PR.

It’s in quotes because I don’t really think it’s a major problem right now but more like something that needs more work from us as a community.

Usually when I mention to people that we have an Ember app in production and that I really like the framework I get responses along the lines of:

“Isn’t EmberJS dead?!?”

“Yeah … only its creators and you use that.”

“Why not React or Vue? “

I know that open source isn’t a popularity contest but for a framework that is that good, has an amazing and very active community and is used in projets of all sizes around the world, it’s kind of sad that we hear such statements when talking about it. Of course it doesn’t need to be number one in popularity, but I still think that we need to do a push on that front.

Questions like this: Is EmberJS dying or just being quietly productive? will probably keep showing up both online and offline and we can use that as an opportunity to make things even a tiny bit better with each interaction.

How do we improve this situation?

Today I read Jessica Jordan’s post which covers this exceptionally well and I will try not to repeat all of her points.

The most important part for me is to reach out outside the community. With one major caveat, we shouldn’t just say: “Hey, we are still here and we are still alive”, but instead promote the things that have made Ember unique and that have made us fall in love with it by making us productive.

The cli tools that save us so much time should be front and center, along with the new testing APIs, the strong emphasis on convention over configuration and so much more. In my opinion the RFC process deserves more attention as well. It is not unique to Ember, but aside from languages like PHP that are developed in a similar fashion, Ember was the first project I saw adopting RFCs and for me reading them from time to time has been great for learning more about it. And seeing that other major projects are moving in this direction makes me very happy.

When asked why I chose ember those are the first things I tell people and I usually get some nods of approval.

If the frameworks is not dead and it’s still absolutely amazing then what’s the “problem”?

For me and perhaps many other people Ember has always been associated with a steep learning curve. Over the years I’ve checked it out a number of times before pushing for it at work and adopting it 100% around two years ago. Each time I tried to get into it it seemed too complex and hard to get started. When that happened we already had ember-cli and getting started was way easier than when I first checked Ember out.

While this has seen a major improvement and the Learning team are doing an outstanding job now that is pretty much a solved problem. The new guides are great and easier to follow than before and what we need to do now is tell people about them, show them how easy ember-cli makes getting started with a new app and point them in the right direction.

Personally, I will probably start working on an “Intro to Ember/Why Ember” type of talk soon to present in front of my local web dev community.

What if my app isn’t ambitious?

Another thing I’ve thought about myself and had people ask me is

Well I am not going to build a huge app, why should I invest Ember

Yes, the benefits of Ember become more obvious as an app grows, however that doesn’t mean that they don’t apply for smaller apps as well.

The only case where I am absolutely sure Ember is not a good fit is when building a single page app is not the goal and we just want to “sprinkle” some components inside a “traditional” server side rendered application.

The technical side

We can go on and on about how to get Ember in front of more people, but let’s spend a few paragraphs on the technical side of things.

One of my favorite things about Ember is the amazing addons developed by numerous developers solving problems so we don’t have to reinvent the wheel every time. And I feel like I should definitely contribute more. With that said, I am pretty sure that some of the things I am going to mention now might have already been done as addons or probably can be done as addons in future.

I will list just a few things so here we go:

• Embracing ES2015 classes and modules fully — this is already possible, but in my opinion it should become the default.
• For me Ember works best as a whole, so I don’t really need to be able to use pieces of it but reducing build size and time will be amazing (and I am pretty sure it’s already on the way).
• The ability to just npm install and import a package is also something I look for and it’s also achievable but not as easy as it probably should be.
• Loading data outside the model() hook is something we all need to do from time to time, but I’ve always felt guilty when doing it. In a lot of scenarious loading one model per route isn’t ideal as well. The solution to these probably isn’t technical at all but it could be discussed more and perhaps added to the docs.

While talking about loading data I think a few words for ember-data are in order. It’s great as it is and JSON-API is a great serialization format, however it’s not applicable for every scenario. The ability to use “non standard” APIs in Ember will be a great addition. This is probably again best done in documentation on how to use other tools instead of ember-data or how to extend it with custom adapters and serializers to use it with custom designed APIs. And of course an addon might be even better to handle those cases (if there is one already, please point me to it).

Conclusion

I am just rambling at this point and I think this is getting too long already.

To summarize:

• open up to the wider community
• make it even easier to get started
• promote what makes Ember great — cli tools, stellar testing tools, productivity
• possibility to use ember-data with non json-api backends

And finally a huge THANK YOU! to the EmberJS team, all contributors and everyone from the community who took part in this call for blog posts! Your are all amazing and let’s go build some ambitious things this year!