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 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
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 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.
Top comments (3)
Very interesting article. Thanks a lot.
I was surprised to read that you are successfully building your design system as web components with Stencil. I expected that it adds to much complexity to share state between SPA and a web component. Would love to hear more how it is working out for you.
Do you have written about that topic as well? Do you mind if I send you a direct message on Ember Discord or Twitter?
Very interesting article, and I totally agree with straightforward structure that Ember.js provides and that it saves developer from inventing wheel everytime.
Can you tell me why did you chose to use Stencil.js, instead of Storybook? (storybook.js.org/tutorials/intro-t...) Is there some special reason? Since, Storybook is much more popular, judging by GitHub star rating.
That's great! Could you please send me a direct message to email@example.com? I need your help, thanks so much!