Ember vs. React: The Pros & Cons of Each

Written by

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

Monthly downloads from yarn and npm for react
Monthly downloads from yarn and npm for ember-cli

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:

  • Facebook, Twitter, Uber, Netflix, Instagram, Airbnb, Amazon, Slack, Reddit, and Tinder all use React
  • Twitch.tv, Apple Music, and LinkedIn all use Ember.js
  • Ember works closely with Mirage out of the box
    • Mirage is a client-side server to help developers simulate a back-end without having to be running against one.
    • Mirage also works with React but requires setup.
  • React is backed by Facebook.
  • Ember isn’t backed by a single company, but rather by multiple organizations (LinkedIn, Tilde, Simplabs).
  • Ember has a lack of dedicated and maintained libraries. For example:
    • In one user's personal experience, he explained he was working on a client’s app in React that relied heavily on drag-and-drop. Getting this to work in Ember was so painful that he eventually migrated the whole app to React because it was easier to find and implement actively used and supported drag-and-drop libraries.
    • In our experience, Contentful, a CMS a client of ours uses, has limited Ember support, and it is largely outdated. This made it so we had to manually build adapters and serializers for a variety of elements coming from Contentful.
  • In Ember, if your API doesn’t follow strict JSON and REST guidelines, you will have to write a lot of extra code to be able to use your API effectively.

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.

Frequently Asked Questions