Considerations in Migrating From Ember to React

Are you considering migrating your Ember app to React?

With explosive popularity and extensive adoption of React within the JavaScript community, many developers have been exploring the opportunity to migrate to one of the most popular technologies in today’s market.

As our Ember friends have begun to explore React as their migration target, some questions we have been asked are:

How does Ember differ from React?

What are the pros and cons of each framework or library?

What mistakes can I avoid if I decide to migrate my application?

We hope to shed some light on these questions and make your migration efforts easier.

Exploring Ember and React — General Differences

When comparing Ember and React, it’s important to realize that Ember is an application framework.

React, meanwhile, is just a library for rendering views.

So we’re not dealing with an apples-to-apples comparison here.

When making comparisons, you can look at the differences between Ember and React in the following ways.

• Ember is an opinionated framework with full features. It is mature and has many Rails similarities.

• React is a flexible, “un-opinionated” library that has a low barrier to hiring and learning.

Ember has been described as having lots of “magic” — many things work by convention. This can be a godsend to many developers and is without a doubt one of Ember’s strongest attributes. If you’re an Ember developer, you’re also probably used to the first-class support Ember provides for routing, data models, and dependency injection.

While you will find that React, the library, does not provide some of these Ember niceties, the React community has stepped in and developed solutions for many of the features Ember developers are used to.

In many cases, these solutions have become de facto choices and synonymous with React development. Some examples include React Router and Redux. But even these solutions have popular alternatives, in line with the library’s and community’s stance on staying un-opinionated and flexible.

Porting Your Ember app to React

One strong selling point for React is the focused nature of the React library itself. Because it’s so focused on doing one thing just right— it becomes very easy to integrate React with other technologies.

React is perfect for cases where you want to add dynamic, client-side functionality to an app that uses other technologies.

Facebook.com, for example, isn’t a traditional 100% client-side app; it sprinkles in React components where user interaction is required and uses other technologies, like server rendering, to generate other portions.

While, admittedly, most of us are not building Facebook, the key here is the ultimate flexibility of React.

When migrating an existing app from Ember to React, the flexibility of React means you are able to incrementally migrate pages and functionality. At the same time, any new pages can be written in React from the beginning.

This approach of mixing Ember and React in the same app has huge benefits, like not needing to drop work on new features to focus on a large rewrite. Still, it comes with its own significant costs.

The most obvious cost is that engineers need to maintain code in two UI paradigms. But perhaps even more important are the potential file size increases.

If you simply import React in the same bundle as Ember, you’ve just increased your bundle size by about 32kB gzipped. To mitigate this bloat, it’s important to use code splitting, which involves creating multiple bundles from some predefined split points, then lazy loading the individual bundles as needed (or using prefetching). Pages that use React could use this method in order to download React only when they actually use it.

Rewriting Your App

The other approach is to rewrite your entire app in one concerted effort. Depending on your team size and resource allocation, this might mean putting major new product development on hold.

Some might think I’m crazy for even mentioning this as a possibility, but it’s actually the most common way people migrate…and for good reason. Why?

If you have buy-in and experienced talent, rewriting your app wholesale can potentially give a huge boost to engineer morale and pay down technical debt. These two factors could lead to much faster iteration on future products, particularly if your existing application is many years old and had numerous different maintainers.

Choosing Your Approach

There isn’t one single recommendation for which approach you should take in every case. Every app and team is different, so you’ll need to evaluate the decisions in your particular context.

For example, if you already wanted to give your app a completely new design (not just a facelift), a rewrite is more likely.

Still, keep reminding yourself that, even if it has shortcomings,your existing codebase works (hopefully). It likely has years of hardening, bug fixes, and performance tuning. While you might have learned from previous mistakes, you will undoubtedly make new ones.

Learning React

Thankfully, there’s no shortage of resources both online and offline for learning React. Aside from the official documentation (which is great), here are some of our top picks:

• The Beginner’s Guide to React | free video series on egghead.io by Kent C. Dodds

• Learn React.js in 5 minutes | by Per Harald Borgen

• React Training Workshop | by Michael Jackson

• Mentoring, support, and migrations| by This Dot Labs

While there are many differences, modern Ember follows a very similar component-centric model that React popularized. However, instead of using separate templates with a custom language (Glimmer/Handlebars) in React, you’ll typically write your markup using JavaScript, or, optionally, with the JSX syntax extension to JavaScript, which is actually just sugar for regular function calls to React.createElement().

Take a look at this simple comparison:

Ember

app/templates/components/example.hbs

<button {action "sayHello"}>Click me</button>

app/components/example.js

import Component from '@ember/component';

const Example = Component.extend({
  actions: {
    sayHello() {
      alert('hello world');
    }
  }
});

export default Example;

React

src/Example.js

import React, { Component } from 'react';

export class Example extends Component {
  sayHello = () => {
    alert('hello world');
  };

render() {
    return (
      <button onClick={this.sayHello}>Click me</button>
    );
  }
}

Ember has the concept of computed properties and observers, while React doesn’t. You could also use the extremely similar MobX library, but I’d recommend trying to learn idiomatic React first. You may not need MobX or Redux!

Conclusion

In summary, the transition from Ember to React is less of a major shift than it used to be now that Ember has embraced components.

However, choosing React means you may have to also choose from a large number of community libraries to provide functionality you’ve come to expect.

The team at This Dot has been through a number of this migrations and can help your team succeed in planning and execution. Whether that’s through stellar mentorships, or providing clean architecture and hands on engineering to your team, we’d like to hear from you.

Get in touch.

Hire the team at This Dot to help

Thanks to Robert Ocel