Page tree
Skip to end of metadata
Go to start of metadata
CategoryWeb Framework
PurposeReact is a declarative, efficient, and flexible library for building user interfaces
Status(tick) Approved
Getting Started


As of October 2016, we are considering our options with regard to React at edX. As can be seen in the "State of JavaScript 2016" survey, most companies are moving towards either React or Angular 2 for rich client applications. There is too much code in edx-platform to consider a big bang switch, so we are evaluating options for an incremental adoption of a more modern technology. This page collects together all of our findings so far.

Why React?

The front end working group was provided with a rubric by edX's Chief Architect with which to evaluate any new JavaScript framework introduced to the platform. The rubric is below:

1. Learning curve / prior experience

2. Options for community - force them down a path or give them options

3. Frameworks that are opinionated vs. flexible

4. Ability to easily build accessible front-ends

5. Ease of design-framework integration

6. DIY framework vs. all-inclusive platform

7. Willingness to dedicate resources to development and maintenance

8. Ease of prototyping

9. Community project support

10. Compliance and security considerations

11. Availability of developers in the region (hiring ability)

12. Most importantly, ability to achieve business strategy

These criteria have led us to select React over alternatives (Angular, Polymer, Vue, Ember) which are variously too prescriptive, inflexible, immature and/or niche.

In evaluating React and alternatives, the front end working group also found these resources helpful:


See Also


  1. Was there a comparison between React and Angular 2? I'm curious about the preference of React over Angular.

  2. Similar question as George. Does the structure of the Pattern Library somehow disqualify Angular yet still allow React (+Redux)? Or would both frameworks be able to leverage Pattern Library with similar amount of effort?

  3. Daniel McQuillen As far as the Pattern Library (or, what we've more recently been thinking about as "reusable components") nothing there disqualifies Angular - we aim to build a system where interested developers can contribute components to a component library, and then use those components to build edX UIs easily and consistently. In this model, the underlying implementation of the components doesn't really matter - in fact, it should be hidden from the developer who's consuming them in the feature they're building as much as possible. So in that model, reusable Angular components are totally possible.

    As far as building features inside edX IDAs, the challenge we have is integration/incremental replacement with Backbone, and we've determined that that's going to be much easier with React than it will be with a more monolithic framework like Angular. So we're planning on building new features in React and slowly transitioning our Backbone applications in that direction as well, following the patterns we've seen from HubSpot, Airbnb and others. As a natural consequence of lots of new feature development being done in React, the components we create that we generalize and add to the reusable component library for building the next feature with will be primarily React. But there will probably be some Backbone components in that library as well, and we're open to the possibility of Angular components being contributed there as well (but less sure how that will work at this point).