Why we use Ember.js at OTA Insight

We always choose the stack that is right for the job. We often get asked why we use Ember.js. It’s not the most popular framework, or the largest community, but it is the right choice for the products we are building at OTA Insight. From our first product, Rate Insight, to the four after that, all of it is built with Ember.js. And for good reasons. We were able to create new features quickly, have a codebase that’s scalable and have a good developer experience. All of these are reasons we choose Ember.js. But let’s go in a bit more detail.

Batteries are included

It’s a phrase you’ll see floating around the Ember.js community and it’s one of the reasons why we were able to move so fast here at OTA Insight. The strong focus on convention over configuration enables you to move quickly as you don’t need to reinvent the wheel every time. It also gives developers new to your codebase a good guideline on how to write code. There’s no 100 ways of doing things.

There were times we had to make something custom, going against the conventions put forth in the framework. This can become difficult, requiring some research into the inner workings of Ember.js, but this hasn’t occurred all that much. The benefits of having strong conventions and guidelines on how code should be structured are more than worth this tradeoff.

What steep learning curve?

The thing I hear developers fear most is the steep learning curve of Ember.js. Not sure where this comes from, especially with the latest move to Ember Octane. After this milestone, Ember.js is making use of the latest javaScript features and it feels pretty close to working with standard javaScript. Gone are the days of having to call custom get/set functions, using EmberObjects, etc.. Now everything is done with class syntax, decorators etc. If you know javaScript, you’ll have no problem getting started in Ember.js.

The templates used in Ember.js are close to basic HTML with the ease of Handlebars added on top. You separate your concerns, having the template and styles separated from the logic. All of this provides a clear overview for developers starting with the framework.

Of course there are still Ember.js specific features you need to know. How is the app structured? What are the lifecycle hooks? What is the Ember.js way of doing things? But this is what you’ll see learning any framework.

Bonus is that here at OTA Insight we have a whole team of people with experience in Ember.js who will be happy to help you out. All you have to do is ask.

Modern frameworks and Ember.js

We’ll regularly check our tech stack and see if we can improve it. Our use of Ember.js is no exception. We recently built a Vue.js prototype of our application to see how it compares. We focussed on 4 factors to determine how they compared:

• Developer experience
• Performance
• Scalability
• Community

I won’t go into too much detail here, that may be a post for later (or if you want to know more, feel free to reach out).

Regarding developer experience it was clear the conventions defined in Ember.js really allowed us to develop things quickly.
Speed was comparable to Vue.js thanks to the Glimmer components recently introduced in Ember.js.
Even now with 5 products, the codebase is still scalable as well, although using a framework like Nuxt you could probably come to a similar result.
Even though there is a larger community with Vue.js, we found Ember.js had a clearer roadmap for the future.

After our research was done we had to decide, is it worth changing our framework to Vue.js? What was clear is that the two were comparable. Ember.js outperformed in some regards, and Vue.js in others as you can see above. We decided that if Ember.js can compete with one of the top three frameworks out there right now, it’s clear this was the right choice back in the day and we are still proud to be developing in Ember.js.

Paving the way

Ember.js is the right choice for our main application. But it isn’t always the right choice. For example, our design system.

Frameworks come and go in the frontend development world, but web components are forever. That’s why we have built (and are expanding) a design system using Stencil.js. Web components can be used in any framework and Stencil.js makes it easy to create new ones.

We did not build this in Ember.js on purpose. While Ember.js has its use, and while we still believe in it now, who knows what the frontend landscape will look like years from now. Having our design system, and so our most generic and most used components be framework agnostic is a huge benefit. It opens the door to have them used with other frameworks (or with no framework at all!) We have several smaller apps, some use Ember.js and some are just plain HTML, CSS and javaScript. In the future we might even have one running in React or Svelte. All of these can use our design system.

We don’t cling to Ember.js just because of a choice we made all those years ago. We do it because we still believe it’s the right choice for our main app. For the design system it wasn’t. We always choose the stack that is right for the job.