Hey, thanks for feedback! 🙂

I appreciate that you shared your frustrations, and keep them in mind.

Your post includes some misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.

That is not to say that React works well for everyone, or that the issues you have raised are not valid. But there are a few facts that I think are important to get right when considering those problems.

I started my app with React 15.5.0 knowing that my code is deprecate before even starting because facebook has just announced that for the next major release they are planning a complete rewrite of the framework and this means that they will likely nuke the current source because it can no longer be maintained.

This claim is not correct, because the “complete rewrite” is backwards compatible. We tried to stress this every time we talked about it, but it’s worth reiterating.

React 16 (work in progress) is a rewrite, but it has the same public API. Out of more than 30,000 (!) components at Facebook, only a dozen or so needed changes, and those few components were relying on unsupported or undocumented behavior.

So this is quite literally 99,9% compatibility. This makes us confident React 16 will most likely work with your code too.

Read more about our commitment to stability without stagnation.

Being not an expert about how to setup a whole project with the framework (and being also skeptical of letting doing my job to a cli tools like create-react-app)

Create React App is a thin layer on top of Webpack and Babel. It doesn’t generate the project code for you, but it configures those tools in the recommended way.

The complaint about boilerplates and starter kits in the next sentences doesn’t sound entirely fair to me, given that there is a solution to that problem, but you intentionally chose not to use it.

There is more work to do in this area, but I think the situation has improved in the past year, and I hope you give it a chance if you decide to try React again some time in the future.

after a couple of hours of refactoring I understood that my code kept growing and it was already 3 times bigger than before due to all the amount of boilerplate code required by redux (ActionTypes, Actions, Reducers, connect…)

Don’t use Redux if you don’t need it, as it is intentionally verbose.

React has a built-in state system, and I would recommend to start with it, and lift the state up when you need to share it between your components.

You can always add them later if you feel the need for them, but starting with MobX or Redux is often too much overhead for little gain.

React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months

I’m not involved with React Router, but I think this claim is not true. If you’ve been following React Router releases, you will know that:

• 1.0 was released in 2015.
• 2.0 was released in February 2016 and is largely backwards compatible with 1.0 (but it added warnings about APIs that would change in 3.0).
• 3.0 was released in October 2016, and is basically the same as 2.0, but with those APIs finally changed.

So if you only updated to stable versions (which you should unless you know what you’re doing), the transition from 1.0 to 2.0 should have been uneventful. You’d see a bunch of warnings, and you’d have 8 months to fix them before the next major (3.0) removed them.

Now, you’re completely right that 4.0 came right on the heels of 3.0. 4.0 is a complete rewrite, and has a slightly different philosophy (which happens to fix many of the issues reported to React Router over the years). You’re right 4.0 was released right after 3.0. The thing is—you don’t have to migrate to it. There are many existing apps using 3.0, and the 3.x branch is still in active maintenance. So you won’t get burned by staying on 3.0 if you’re already using it, and the team is working on making the migration path to 4.x easier—for those who are interested.

So the bottom line is: if you only used stable releases, React Router gave you a whole year to migrate to new APIs. They released a 4.x rewrite to fix some long-standing issues, but commit to maintaining the 3.x branch indefinitely. Doesn’t sound too bad to me!

Once I understood what was the issue I was dragged into the rabbit hole being forced to add empty divs all over the place to let my app work properly

you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation

Glad you mentioned that! React 16 will support returning arrays from render() so you can delete all those nasty divs and wrapper tags. We’re working hard to make your life better.

React seems to be an enhanced rendering framework born to replace the use of server side files (probably PHP) mixed to HTML as confirmed by this tweet

It is not quite clear to me what exactly you mean by this. But if you’re interested in why React makes sense to us (and folks at Airbnb, Twitter, Pinterest, and other product companies), the way I usually explain it is that it helps us build apps with less bugs thanks to explicit data flow and lack of manual DOM management. It’s great if you found different strategies for dealing with these problems, as we all learn from each other.

This article digs into why some people find React useful so I encourage you to take a look at it! But it’s totally cool if React doesn’t solve that problem for you, or you prefer a different set of tradeoffs provided by great alternatives like Vue, Ember, and Angular.

its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code

This is not correct, as you can use React without ES6 and without JSX if you prefer so. Then it’s as simple as dropping a single script tag in your app.

But we do think build toolchains are useful (even you think so—given that you mentioned you’re using a linter). While they are not always easy to configure, we hope that solutions like Create React App will make them more accessible, and the underlying projects (e.g. Webpack) will get more user-friendly over time (Webpack 2 is making a lot of progress in this area with config validation). So I’m optimistic about them, but I see why people might want to use React without them.

you will need to import in your scriptsreact-dom and react without never using the last one instance for some wild reason known only by the React team

The reason JSX transform requires React to be in scope so that JSX works with browser globals. Which is related to your previous complaint: we want JSX to work even if you don’t use a bundler!

you must use className instead of class to define the DOM css classes

You are completely right it’s annoying. It’s one of those early design decisions to align better with the DOM APIs that has proved to be confusing. We might change this in the future.

what do you expect from a framework with more than 1000 issues on github

React Native has a lot of API surface area, and is very popular, so naturally it gets a lot of issues. Many of those are support requests, but we appreciate all the help fixing bugs and helping people in the issues.

that will let you install alpha dependencies by default (React@16.0.0-alpha.6) to develop your native app?!?

The version of the react package is generally not relevant for React Native users because it contains very little code (Component and createElement). The reconciler code is synced to React Native separately. So this an artifact of the different release cycles of RN and React, and doesn’t at all mean that RN apps are using an unstable version of React. This is the same exact version we are using at Facebook in production. I agree it’s confusing though, and we hope to align the release process between React and React Native more closely in the future.

To sum up, I’m grateful that you brought up these concerns in an article. They come up pretty often, and I thought it is important to separate the facts from misconceptions. But there is definitely more work ahead both for us and for the ecosystem to deliver a better experience to React users, and I’m glad you articulated those common issues so we can better address them.

Edit: I would like to thank everybody who pointed out the first version of this article was too passive aggressive. I’m very sorry about this! I edited the article to a more professional tone, as I should have done before posting. I also removed all emojis but you can still find them on my Twitter. 🙃