How to migrate from React.js

Due to recent news, you might consider moving away from React.js or any technology under Facebook’s BSD+Patents License. If you are considering migrating or if you're trying to evaluate the scope of a migration, we've provided you a table of contents to determine what you need to know.

Table of contents

• The Issue
• Effected Tech
• React to Preact
• React to Vue
• React to Angular
• Flow to TypeScript
• Jest to Mocha, Chai, Sinon
• create-react-app to other CLIs

The Issue

Facebook's lawyers' response to their engineers who inquire about their open-source projects, is that they require the BSD+Patents License. The license is meant to be a defense from people suing Facebook for patents. While this is an "old idea" for lawyers, the result of re-introducing it in the open-source community comes off as tone deaf to the original intent of open-source. The following is one technology lawyer's response to another who believes this isn't a huge issue.

I'm also a technology lawyer, i've written several of the patent grants used very widely, as well as having been responsible for open source licensing compliance at Google for a very long time .
If i thought this license would actually help i would support it in an instant. But so far
1. i don't believe it would. It's a very old idea, discussed to death, with a lot of downside, and a little upside.
2. they've ruined a lot of the possibility of getting people on board by doing it in a way that's fairly tone deaf.
As for the license itself:
You also have the same concern if you aren't large.
It's also not just going to yank your react license, it will yank your license to everything under this license.
This license will not have the effect of stopping patent litigation. Patent trolls don't use React, and most of the danger is still trolls.
If you really wanted to play that game, you'd be better off saying "if you sue us, you lose the right to use facebook the service". That might have some effect (but probably not a lot).
Instead, this license will have the main effect of further enabling the large to leverage the small. Hey, seems like you got technology i like, and hey, looks like the app you depend on for your livelihood uses react. it'd be a shame if you had to sue us for taking your stuff and lose your react license.
Do i think facebook will do that? Honestly, no. I doubt it. They may by accident. Do i think, if widely adopted, it would have that effect: 100% yes.
As for the origins, these kinds of broad termination clauses have been around forever. They aren't anything new. As i've said before, they were considered and explicitly rejected from most current licenses with patent grants.
Rather than come to a community of license authors, etc, and say "hey, we want to re-explore this, because we're seeing a problem", they did it this way. That's ... unlikely to be a successful mechanism (and in fact, i know a large number of corporate counsel who have banned it).

If any of this scares you, (and it should) you're probably considering migrating. Don't worry, I got you covered with the best migration paths.

Effected Tech

Facebook's open-source is pretty vast covering everything from UI frameworks to creating their own language. We're going to focus in on four technologies: React, Flow, Jest, and create-react-app.

• React Introduced as the V in MVC with the sole focus on rendering the view. The goal of React is to provide a developer with a simple API that others can build on top. The team behind React provides a simple common abstraction much like what Node.js did for running JavaScript as a server. If you build anything that depends on React you are affected by it's license.

• Flow As the scale of our applications grew larger, we started to run into common problems within our codebase. Basic errors such as typos or using a function incorrectly due to poor documentation happen due to human error. Using a typed language allows the developer to avoid testing for human errors such as incorrect inputs or types. If you build anything with Flow you might be affected by it's license.

• Jest Known as the zero configuration testing platform. The idea here is that the testing framework knows you're most likely building an application which allows them to provide you with all the essentials. If you test anything using Jest you might be affected by it's license.

• create-react-app This CLI creates a simple hello-world application. There is also a large readme explaining everything you need to know about expanding from your hello-world. If you build anything on top of React you are affected by it's license.

React to Preact

The quickest way to migrate out of React is to move to Preact using their helper package called preact-compat. Preact also provides the good parts of React's API without the overhead or bloat of the framework that never really changed after it's release. Building on these ideas, Preact was able to excel on areas such as higher progressive web application score using lighthouse. also has better support for web components compared to React. Other differences also include server-side rendering and performance which is better in Preact than React.

Why

Preact has a familiar API as React using pattern like ES6 classes and Functional Components without anything else like React.createClass, Synthetic Events, PropType validations, React.Children, and a lot of virtual-dom optimizations. At the same time the team behind Preact also provides a helper package for migration from React. Preact is highly optimized focusing in on the key parts that makes React so great while providing you with the best performance. This is why we think Preact is the perfect first choice when moving off of React to an MIT licensed framework.

Preact is a 3KB alternative to native React. This is accomplished mostly in part to lightening up the original React API and removing the Synthetic Events, PropType validations, and the ability call React.Children. React provides an optional add-on called, preact-compat if any of the aforementioned features are needed.

Switch to Preact with just one command line

You can migrate from React to Preact with just one command using bye-react. More specifically, this tool switches the project over to preact-compat, the "compatibility layer that makes React-based modules work with Preact, without any code changes".

$ npm install -g bye-react
$ bye-react

If you want to undo bye-react you can simply run.

$ bye-react --undo

This is the fastest way to switch to Preact because the tool does 3 things that you would have to do manually.

• Transforms your build system if you use Webpack, Browserify, or the Babel React preset (or any combination thereof). If you don’t use any of these tools (although you probably should), this won’t work.
• It's not guaranteed to work in all cases so for some, this is a great first step. Note: Make sure to create a new branch if you plan to migrate this way. Also be sure to use a version of React that is compatible with the current stable release. Failure to do so may cause interesting and unfortunate ways with non-standard build pipelines (e.g. if you dynamically generate .babelrc or package.json, etc).
• Will delete comments inside package.json and .babelrc files. These files contain JSON-compliant data. To add the aliases, bye-react reads in the JSON, modifies it, and writes it back to disk. Comments are lost en route. If these are important to you then don't use bye-react.

There are two more methods in this guide provided by Preact

• bye-react: one line CLI to migrate from React to Preact
• Switching to Preact (from React)
• Using Preact Instead Of React
• Differences to React

React to Vue

Unlike React Vue is a full framework offering a router, state solution, and even scoped styles out the box. In React you're always worried about choosing the right package for state, routing, styles, or any other missing part that React doesn't provide. Vue assumes you are creating a web application so they make sure to guide you along your way with a ton of documentation on all parts of the framework. They even go so far as to compare Vue to others and give you an idea as to why they made a certain design decision. This framework truely feels as it was built by the design of it's community because it was initially just like React (just the View) before it grew into a full web framework that it is known for today.

Performance

Vue was created with performance first by design. Each part of Vue reminds you of how much thought was put into it's design in order to achieve it's performance from all the learnings the community found in React. For example their virtual-dom does all of the optimizations that you want in React but by default. Vue also made sure you can still use the framework by simply dropping a script tag in your index.html and easily get up and running without losing performance for file size.

Scale

When talking about scale for the frontend you endup talking about how many engineers can work on the project without losing their minds with merge conflicts. This framework also likes to call itself progressive since you can easily scale the abtraction level high or as low as possible with a simple script tag.

Why

Vue allows you to use both JSX and Template but more of the time you will find yourself using the template syntax. Unlike React where you're always faced with decision fatigue, in Vue.js you are able to focus on your application code with a clear API that doesn't try to introduce any new terms. We think Vue.js is a great choice for migrating from React and more so for green field projects. If you want to get up and running with your application in minutes you really should give Vue a try.

Resources:

• Switching From React To Vue.js
• (Vue) Comparison with Other Frameworks

React to Angular

When migrating to Angular from React there are many differences that you should be aware of. While some of the concepts of React remain with Angular, they are different architecturally. Here's a quick list of differences.

Design Differences

• Bootstrapping While in React this is as simple as importing a render function from react-dom, in Angular we need to import not only the browser version of bootstrap but configure an internal runtime. Your main file for starting your framework is going to be completely different when switching.

• Props In Angular you have props but they're called Inputs and only allow values that don't include functions. As with react you're able to use unidirectional data flow in Angular using Inputs.

• Prop-Types In Angular you're most likely using TypeScript which will tell you that you're using the input incorrectly so you won't need runtime type checking as it's in the build system and editor.

• Styles In React you have to find your own way to manage styles in a way that works with your team. In Angular this is solved by using the browser API to emulate scoped styles as if you're using the Shadow DOM. So, rather than having to choose which style library works for you, in Angular it's built-in.

• Storing State Both frameworks allow you to store local state within the component which affects rendering to his child components. Angular also provides you with ways to wire up any sort of store with it's services.

• Event Handlers While in React you have hard coded events, in Angular this isn't the case. In Angular you can use the framework's method of wiring up events that will work for any event name called Outputs. In both frameworks you can also get a reference of the element to manually wire up the listener.

• State Change While in React you must use setState in order to make sure your changes are reflected, in Angular you don't. In Angular you simply change the value in your component and the changes are batched and reflected automatically. Angular uses zone.js to track all asynchronous calls and this comes in handy when doing server-side rendering.

• Data Binding with Unidirectional Data Flow Angular allows you to benefit from both one-way data binding as well as two-way data binding without losing out on the benefits of unidirectional data flow. This is one of the best features of Angular as you keep the benefit from previous patterns without a performance loss.

• Refs React provides you with escape hatches where possible and Angular does the same with ElementRef. Angular also makes sure to prevent you from getting direct reference to the element so it can be garbage collected.

• Component Composition Practically the same as React, in Angular you're able to compose many components within each other as well as use content projection. Angular also allows you to use native browser slot API for better interoperability and composition. You can also use the native Shadow DOM API to truely encapsulate your component and styles.

• Dynamic Elements In React we're able to use JavaScript for dynamic repeating elements. In Angular we use structural directives to declaratively tell the compiler how to wire up your dynamic elements

Why

Angular is the second biggest framework right after React so there is already an established ecosystem. There are also lot's of opportunities for a company or engineer to become notable in the community. The project is backed by Google which is much larger than Facebook and the Angular Team is close with the Chrome Team so they're able to foresee future changes to chrome that will affect the framework. For example, the Angular framework was built to support web components and is optimised to work well in V8's VM due to patterns they discovered while talking to engineers at Google.

Flow to TypeScript

Why

TypeScript is the leader in Typed JavaScript so naturally it's the best choice. It was created back in 2012 so the codebase and community are both very mature when compared to Flow. TypeScript remains a great choice considering how much has been invested into it's syntax while also making sure to follow changes to the JavaScript. You can think of TypeScript as a superset of JavaScript.

Differences in usage and usability

	TypeScript	Flow
Leading Design Goal / North Star	identify errors in programs through a balance between correctness and productivity	enforce type soundness / safety
IDE integrations	top-notch	sketchy, must save file to run type-check; some IDEs have workarounds to run real-time
type-checking speed (w/o transpilation, subjective, need benchmarks!)	speed does not degrade much as the project grows	speed degrades with each additional file
autocomplete	both during declaration and usage feels instantaneous feels reliable	only for usage feels sluggish (often a second or more of delay) feels unreliable (sometimes does not show up at all)
expressiveness	great (since TS @ 2.1)	great
type safety	very good (7 / 10)	great (8 / 10)
specifying generic parameters during call-time	yes e.g.	no
specifying generic parameters for type definitions	yes	yes
typings for public libraries	plenty of well maintained typings	a handful of mostly incomplete typings
unique features	autocomplete for object construction declarable this in functions (typing someFunction.bind()) large library of typings more flexible type mapping via iteration namespacing	variance existential types * testing potential code-paths when types not declared for maximum inference $Diff<A, B> type
type spread operator	work in progress	shipped >=0.42
ecosystem flexibility	work in progress	no extensions
programmatic hooking	architecture prepared, work in progress	work in progress
documentation and resources	very good docs many books videos e-learning resources	incomplete, often vague docs
commercial support	no	no
error quality	good	good in some, vague in other cases

Resources:

• Migrating from Flow to Typescript
• TypeScript vs Flow

Jest to Mocha, Chai, Sinon

If you're using Jest, then the switch to Mocha should be relatively straight forward. Mocha is very flexibility by design but has one downside in that it requires more configuration. One of such, is having to choose an assertion library such as Chai and Sinon for mocking. Another benefit of switching to Mocha is the community and large support with videos, blog posts, and libraries. Mocha also provides snapshot testing as yet another integration with either snap-shot-it on npm. With Mocha there will be a lot configuration initially but once you're all set and ready, your workflow would be better off due to the outstanding community support.

resources:

• React Testing – Jest or Mocha?

create-react-app to other CLIs

A great way to initially create your project is using a CLI since it allows you to focus on your application code rather than learning your build setup. The main difference between React's CLI in comparison to others is that other CLIs have more features while React's create CLI has large documentation around their initial scaffold.

preact-cli

Start building a Preact Progressive Web App in seconds 🔥

In this CLI you also get routes wired up by default as you're most likely going to create an application with them. Unlike in the React CLI.

vue-cli

A simple CLI for scaffolding Vue.js projects.

Vue CLI provides you with template so at any point you and your company can create your own template starter. This means the CLI is already better than others because of how often teams disagree with the initial setup.

angular-cli

CLI for Angular applications based on the ember-cli project.

A lot of patterns and conventions in Angular are automated with this CLI which allows you to focus more on the app

Resources:

• preact-cli
• vue-cli
• angular-cli