We chose Ember in 2015 and it is still a good decision in 2020

… and will be in 2021 in my opinion. Here is why, but first:

A bit of background

Phorest is a company with a product that has evolved a lot in the last decade. Its main application is a desktop app that talks to a database in the Cloud (AWS). Being in the process of moving that desktop app to web, we had to choose (and bet on) a front-end framework that will help us accomplish our goals quickly and with high quality. Ember was that choice.

Here are the main characteristics that we hoped for and that have proven to be true.

Conventions

It can seem counter-intuitive but, some “limitations” and so-called conventions can save you a lot of time in the long run and ensure the high quality of the product. It’s not a new concept and the most prominent example is probably Ruby on Rails. It’s not really about not being able to do something but doing it in a certain way. In other words, having a solution for how to do common things.

We all depend on other humans’ work and we don’t have to reinvent the wheel on every project we start. Knowing that a lot of people around the world have tested strategies that you are going to use can calm your soul. You can focus on business value. Users really don’t care how you manage the state in your app. It just has to work.

With that said, Ember offers much more than React or other frameworks. There is a whole philosophy on how you should do things. Of course, the learning curve is steep because of that but on the other hand, if you’ve just started with a framework you don’t experience decision paralysis, thinking:

• how to manage your state (what library we should use?),
• what’s the best router library?
• how to “reuse” the data you’ve already fetched?
• how to work with different sources of data?
• how to organize your application structure?
• what testing library is going to be cool in 2021?
• how to deploy my app?

Ember has you covered and that will boost your productivity and building speed. There is no reason to pretend that we don’t live in the business world. Being fast and producing high-quality software is important for every software company. No matter if you are like Phorest — 17 years into building software or you are a startup that has to get the job done quickly.

We don’t have to reinvent the wheel

I’d like to stress out this part. After all, every ready to use solution you see in Ember is just a code. You could write it on your own. But it will take time and the chances that you will miss something are higher.

Let’s take adapters and serializers for example. At Phorest we have different sources of data, with different standards used. It’s maybe not ideal, but this is how it is if the company you work for has more than one API. With the right architecture, you don’t have to think about how one of your servers likes the data to be served. You just have to configure that once, and chances are very high that there is already an addon that will handle the communication for you.

Later on, in your code, you’ll not be able to differentiate that data comes from servers that speak very different standards.

Stability

The last thing you want is to take BIG steps when upgrading your framework of choice. Software evolves. It has to. Only small Linux terminal tools can be considered as finished. But web frameworks will change.

Ember follows 6-week cycles when releasing a new version of the framework. That’s very predictable. If they decide to remove something from the API you should not be surprised. A lot of new functionality is first discussed in RFCs. And the best part… it is often introduced as an addon (plugin) to the framework. This way, the maintainers can gather early feedback without introducing something to the main code.

Another thing worth mentioning is codemods. Changes in syntax are often accepted only if there is an automated script (codemod) converting old code into new. I’m not sure which framework first started using that approach but it’s in Ember’s philosophy for a long time.

Ember used to advertise itself with “stability without stagnation” and that’s true. Recently, the motto had to be changed into something more catchy but that rule is kept in my opinion.

Ecosystem

Ember is rather known for a good ecosystem of libraries and plugins. Ember Observer project should help you in understanding how well maintained libraries are. Some of the popular addons where authors were no longer able to continue their work on it were adopted by the Ember community. That tells a lot about the maturity of the ecosystem.

So again, something important for us, we see that people take it seriously and we are not that worried if some dependency will be abandoned.

When possible we try to add value to the ecosystem and collaborate on addons and tools.

Community

Ember’s community was always described as friendly and we can confirm that in our journey. Unfortunately, it’s not that big as for other frameworks but so far we have not stuck on any problem and you should be able to find useful information just by googling the problem.

That’s important because every developer searches for solutions in their everyday job. Picking a trendy but buggy framework with a still relatively small community can turn your work into a nightmare. To be honest, Ember was in that band a few years ago. It wasn’t easy to find a good solution and the SEO of official guides and API reference wasn’t great. That often led to outdated information. But those days are gone.

Future

Ember is evolving to use native ES6 features and the newest techniques in the front-end world. That’s not easy for a framework that is around for a few years. Actually, something that people don’t like Ember about — `Ember.Object` — paved the way for modern implementations. But that legacy is problematic now. The Ember Octane project is the answer to a lot of pain points and killing the so-called “Ember Way” (click here to see a cheat sheet with a comparison on what changed).

We see the future of the framework’s evolution as bright.

It’s not all rainbows and unicorns

Of course, we have to be fair. I don’t want to justify our decision for all cost just to say “it’s great” with tears in my eyes. No. I just want to say that for us using Ember was a very good choice.

With all bets like this, you pick a tool for a job and you’ll see what happens.

So let’s see what the downsides of using Ember (for us) have been:

• it has a reputation of hard to learn with a high learning curve and,
• it doesn’t have a sponsor with huge marketing budgets (like Angular and Google, React and Facebook) — so it will stay niche,
• its building process, once the best in class (or even a pioneer), is now obsolete and has to be replaced with something modern and popular.

A common belief that we found not entirely true when talking about downsides, is that Ember has a relatively small community so it’s not easy to find someone for a job. While we get fewer applications, the people that claim to know Ember seem to know it better than people claiming to know React actually know it.

Summary

We are all in. It worked for us and saved a lot of time during our journey. The worst that can happen to us is a collapse of the community but we don’t see it happening in the foreseeable future.

Happy coding with Ember 🙌

Tomek Nieżurawski writes also on his own blog — tomekdev.com.
Special thanks to Aaron Chambers and Jonny Green for their feedback.

We are always looking to speak to amazing engineers about joining the Phorest team. You can check out open roles here