Ember vs. React: The Pros & Cons of Each

I’ve been using React since the second year it was introduced to the industry, and I’ve just completed a project using Ember. After my experience with both, I thought now would be a good time to reflect on my thoughts regarding the strengths and weaknesses of each of these frameworks. In this article, we’re going to compare and contrast both frameworks in different aspects of the development process:

I. Access to knowledge and information

These images are to illustrate the difference in the number of downloads, and therefore the number of developers using React or Ember currently. Ember has significantly fewer developers using it and is hampered by this lack of engineers. Fewer developers mean fewer people writing articles, asking questions on StackOverflow, and spreading information. For one problem I had, I couldn’t find an answer anywhere, so eventually, I had to join the Ember.js Discord and read through months of old chat logs in order to find an answer to my question. In contrast:

React has good documentation and great online resources

The React docs are good and are accompanied by a wealth of knowledge and information being spread via threads online. More often than not, if you run into a problem, someone else has run into that same problem and you can find a reliable answer after a Google search and a bit of reading.

Ember has great documentation, but a lack of online resources

The Ember docs are great and explain general concepts very well. That being said, they will largely be your only reliable resource. There are significantly less helpful online resources for Ember because of the lack of developers; but also, because of the introduction of Glimmer components. Glimmer components changed the way components and logic files look and act in all Ember apps after version 3.15. This makes it so that most of the few resources that do exist online are nearly unusable or require heavy reinterpreting because they were written entirely differently before Glimmer components were introduced. 

Because there are fewer resources online about Ember, you will often be left to either find your answer through trial and error, or you may have to join specific Discords or search for other resources that can help you.

Conclusion

• React is a clear winner here. Not only has the framework been around long enough, but it’s also continuing to grow and has always had a large number of developers. 
• These factors give the developer more resources to look at to answer questions and learn the framework more easily. The quantity of questions is larger, and the general quality of the question is better for future developers because React has largely stayed the same where it matters.
• Ember was more popular in its previous form without Glimmer components, which makes many of the few resources that do exist today not very useful because they don’t work or require a reinterpretation.

II. Configuration or convention?

React chooses configuration

React allows you to build your repository your way. You can choose your state management framework (Redux, mobX, Hooks), your routing framework (React Router, wouter), and most of the time you can put files where you want. This allows for greater flexibility and more choice for the developer to build their app in a way that makes sense to them and their team specifically.

Ember chooses convention

Ember has strict conventions and patterns that it expects all developers to follow. It comes with its own router which it expects you to always use. Ember also comes with a specific way to give actions and states to a component, primarily the store, tracked variables, and actions (reference).

Not using set conventions can make it harder to switch between multiple codebases because the owners of those repositories might structure things in a way that is different than your previous team. With Ember, this shouldn’t happen because of the strict project structure guidelines.

Conclusion

There is no set winner here. Ember’s strict project guidelines make it easier to jump between repositories, but it does enforce those guidelines. If you or your team don’t like those guidelines, or would rather have more control over your codebase, then React wins this category.

III. Project and File Structure

In React, a file name matches the component’s reference in code: 

In React, a component or file referenced in code will match the name of the file in the repository. Also, all files used in a component are imported at the top of the file. This makes it easier to find files and understand what you need and where it is because doing a global file search for the name of a component will almost always find the matching file correctly. 

In Ember, a file name is dasherized and may only represent part of the component’s reference in code

In Ember, a component or file referenced in code is in the pascal case, but the file name itself is dasherized.  For example, think of a component placed in the repository at app/components/cart/certificate-summary.js. The first line of the component would be export default class CartCertificateSummary extends Component. On top of this, logic and templating are done in separate files generally both named the same — in this case certificate-summary.js for logic and certificate-summary.hbs for templating. This makes it even harder to find all the information you need quickly, especially for junior developers?.

In React, logic and templating are done in the same file

I touched on this in the last point, but it should be made again. In React, generally a component’s logic and templating would be done in the same file. The logic is done in functions on the component and the templating is done in the render function. This consolidates the component and allows a developer to work on logic and templates without having to look for and switch between multiple files. 

In Ember, logic and templating are done in different files

In Ember, a component has a template file and a component JavaScript file. This makes it so a developer has to search and constantly switch between multiple files to work on the logic and templating they need for the component they’re building. If you’d prefer things to be more self-contained, this may not be enjoyable for you.

Conclusion

Once again there is no clear winner here. However, in my experience, React has been easier to navigate. Although you may have an easier time with Ember if you’re coming from Ruby on Rails as the project structure is generally similar. You’ll also want to consider if you’d like to keep logic beside your component in the same file or have them be separated into logic and template files.

Other notes

These last items aren’t direct comparisons, but rather things to be aware of for each of the frameworks:

Both of these frameworks have pros and cons. Your preference will largely depend on your preference regarding convention over configuration, and the separation of component logic and templates. However, I would heavily consider the lack of usable and helpful online resources when looking at starting a project in Ember. 

If you would like to explore further, check out our React consultancy and Ember consultancy pages.