I believe React.js, Flux, Redux, Relay and companions are great tools for building front-end code, however after few production projects i realized that the react ecosystem is not always the perfect choice for any project and team.

To React or not React?

Below is a critical look at React.js, mainly questioning the common thinking that React.js is perfect, ultra-performant and superior to other options.

Inherent complexity

Yes, React combined with Flux/Redux/Relay is harder to understand and work with than Angular 1.x and other common MV* Frameworks. My first thought after working with Angular 1 was "Huh, simple and intuitive" -- With React it was"WTF?!".

There is a learning curve, and a new team coming to React will have a significant drop in productivity, since they need to re-learn building front-end code. Almost perfect modularization of components and complex communication patterns are harder to understand and work with.

Is maintainability worth a drop in productivity for a team new to React?

Investments in maintainability might pay off in the future, since we tend to spend much more time maintaining existing code than writing new code. However, maintainability is very subjective.

Coming from jQuery/Angular to React reminds me of a transition from a monolith to micro-services, because you break up a few views and controllers into 100s of smaller components that you compose in a deep hierarchy and connect with reactive communication architectures. As with micro-services implemenation, first time you will shoot yourself in the foot, but the second or third time you will build it right.

Experienced React teams OR expert JavaScript developers should not take a significant productivity hit, but still 99% of the people out there don't know enough JavaScript to qualify as experts.

Yes, you watched 10 tutorials and built 3 apps, it is very easy for you, i know. However, most people learn by doing costly mistakes. Our first React architecture was using Fluxbone, and it was horrible (pro tip: don't combine Backbone with Flux).

Experienced React teams might be able to build really amazing and maintainable UI architectures, proven by Facebook, AirBnB and others. However, a recent post on Quora by Digital Ocean engineering manager is not reinforcing the claim that A-league teams can adopt React easily:

"When building our help section for the control panel, we tried building it in React+Flux but found ourselves fighting the framework a lot. When we decided to experiment with building it Ember, development went much speedier." - Jenna Zeigen, Engineering Manager at DigitalOcean

Also individual developers are trying to find help on Stackoverflow, Codementor and similar. Recently i got the following request on Code-Mentor:

Redux-saga is missing dispatched actions and not invoking the generator that is expected to be called when that particular action is dispatched.

No wonder people have challenges. Complexity kills.

JSX is necessary evil

What is JSX anyway?

It’s actually a declarative syntax that’s used to express the virtual DOM. JSX gets interpreted and converted to virtual DOM, which gets diffed against the real DOM. Rather than rewrite the whole DOM tree, only the differences get applied. That makes React renders fast.

Seemed interesting at first look, but JSX love turns into JSX hate very quickly. Everyone accepts it as necessary evil under the excuse that you get better performance with the Virtual DOM. However, that is an implementation detail, and performance doesn't make JSX syntax and limitations more appealing. A performant engine doesn't make an ugly car more appealing.

React JSX ugliness

Yes, you can use plain JS instead of JSX, but then you get even more complexity when composing the UI. Many people frustrated by JSX are looking for alternatives:

What alternatives exist for JSX

JSX might not be a completely failed concept, but the implementation has not made everyone happy. Still, it might be one step in the evolution to something better.

JSX - The other side of the coin

Relay and Graphql - Anyone?

Relay and GraphQL are not yet adopted by the community as much as Flux/Redux and friends. Seems that advanced architectures are not yet appealing as the "simpler", and better documented alternatives.

Webpack is a black-box

Webpack is not maintained by Facebook directly, but still it's worth criticizing since it's heavily used by React teams.

Webpack is more complex than Browserify or JSPM in many scenarios. The unreadable declarative approach to configuration reminds me of Grunt because most of the time you have no idea how it works under the hood, but it works most of the time -- one line of configuration does 1000 black magic tricks. Not to mention the configuration is only understandable to "webpackers". Here is an example:

module.exports = {  
  devtool: 'eval',
  entry: [
    'webpack-dev-server/client?http://localhost:3000',
    'webpack/hot/only-dev-server',
    './src/index'
  ],
  output: {
    path: path.join(__dirname, 'dist'),
    filename: 'bundle.js',
    publicPath: '/static/'
  },
  plugins: [
    new webpack.HotModuleReplacementPlugin()
  ],
  module: {
    loaders: [{
      test: /\.js$/,
      loaders: ['react-hot', 'babel'],
      include: path.join(__dirname, 'src')
    }]
  }
};

Even the webpack comparison guide confirms Browserify might be simpler to use:

The Browserify ecosystem is composed of a lot of small modules. In this way, Browserify adheres to the Unix philosophy. Browserify is a little easier to adopt than Webpack, and is, in fact, a good alternative to it.

Webpack is as opinionated as React. Once you start using it, it's hard to go back, since your code is polluted with Webpack-specific syntax (imports and loaders). Pretty much the same applies to Browserify. Importing CSS and Images is really strange for newcomers to these tools. Here is an example of a CSS import:

require("css-loader?sourceMap!./file.css")  

Webpack is a good choice if you have experience and understand how it works. Webpack has a lot of advanced features, if you need them. The main value proposition of Webpack is bundling and hot-code reloading:

Webpack deals with the difficult problem of bundling, but there's so much more. I picked up Webpack because of its support for Hot Module Replacement (HMR).

Of course you can achieve bundling with other tools as well, so again, Webpack is all about advanced scenarios.

JSPM combined with SystemJS seems like a very interesting approach as an alternative to Webpack or Gulp + Browserify.

http://ilikekillnerds.com/2015/07/jspm-vs-webpack/

React is not the king of performance anymore

With the rise of Angular 2.0 and other libs and frameworks copying React mechanisms or optimizing their own, it is questionable if React is still the king of rendering performance.

Angular 2 rendering architecture

React still supports server-side rendering as a performance optimization

Now Angular 2 and others support Server-Side rendering too, so React is not the only universal SPA library anymore. Seems that React lost it's main positive aspect in comparison to other libraries and frameworks.

Types are a second-thought

A library that does not adopt optional types in JS will get negative points from me. I believe TypeScript to be pretty close to the future JavaScript, and Angular 2.0 (and even Aurelia) embracing it as a default will be a winning move. React also supports types with TypeScript or Flow, but still it's not the default.

I hope React will include default support for optional types at some point. Even Dart has it!

In case you want to try to setup TypeScript in React check out:
React and Webpack Typescript handbook

React opinionation easily turns into a religion

React is pretty opinionated (with JSX, reactive communication patterns etc.) and people tend to get religious about React quickly after building the first hello-world app. It probably has to do with the Stockholm Syndrome.

Stockholm syndrome, or capture-bonding, is a psychological phenomenon described in 1973 in which hostages express empathy and sympathy and have positive feelings toward their captors, sometimes to the point of defending and identifying with the captors

I surely felt the deep connection to my captor (React) after i spent hundreds of hours learning it and working with it. Every developer loves complexity.

So let's chill out -- there are many valid options out there. In the end what matters is to build the freakin' UI and make it work for the user with satisfactory usability and performance. Team productivity is important too, and maintainability is relative to the builders. My code is always the best of course.

Final Remarks

Even though this article is focused on a critical view of React, i must say it is still a very strong universal UI library.

Componentization is the way to go and if built correctly, a React app can have a clean architecture. However, everyone should be aware of the challenges and limitations of React and companion tools.

Also, for anyone still in doubt, React is not killing Angular

React is worth the ride, and i recommend to try it on a real app. You will learn a lot.