Last modified: June 13, 2017
React.js is one of today's hottest options for front-end development. By emphasizing things like ES6, flux architecture, and component based rendering, React points towards "the future" of web development. From a performance standpoint, it crushes Angular 1 and has Google's Angular 2 scrambling to keep up. The Facebook owned framework has a strong and growing community and the momentum surrounding React.js is palpable to any front-end developer. What's not to love?
While it's hard not to get caught up in the hype that is React.js, we explore some of the major arguments against using React.js. We've listed some of the major reasons below. Keep in mind that this is not a full fledged argument against using React, but rather an exploration of why using the library may not be appropriate for every project.
React follows the flux architecture, meaning it uses unidirectional data flow to update and render DOM elements. This concept can be hard to grasp if your coming from other popular architectures (like MVC) and takes some getting used to. For more information on flux architecture, see Flux vs. MVC.
React also uses JSX, which essentially adds XML syntax to the traditional HTML templates. While JSX makes creating JS based React components easier, it takes some getting used to. Specifically, adding things like classes and css styles becomes more complex when implementing components and templates with JSX.
React indirectly relies on a lot of tooling to make things work. First, webpack is used with babel to transpile ES6 and JSX into browser friendly ES5. While it's possible to use React without these technologies, things will get very verbose, very fast. To fully benefit from the React.js library, it's highly recommended that webpack is used.
Since such dependencies (webpack, babel, React) are easily managed through Node's npm, it can be argued that React.js indirectly relies on Node.js as well. Like webpack, it's entirely possible to use React without Node, but it makes things a lot more difficult.
When you add it all up, React is relying on a lot of external libraries/dependencies to make things happen. If developers aren't as familiar with these tooling options (or the Node ecosystem) then getting started with React may take more time than it's worth.
React is a Facebook product. It was designed by Facebook to address Facebook's needs. This doesn't necessarily mean that it's the best option for solving your needs. Specifically, React is optimized for frequent rerendering and avoiding the high performance costs of template diffing.
This is great for the Facebook app since it relies on a complex set of interactive components that are constantly being updated by user events. Unless your building a social network or a single page web app (SPA) that relies heavily on user interaction, React will add a ton of bells and whistles that aren't worth the hype. If you are a content publisher or largely displaying static content, using vanilla JS could be a better option.
React.js is a great library and it isn't going anywhere. Anyone can argue it's superior performance and viability for implementing scalable front-end solutions. Despite such strengths, it's important to remember that React is ultimately for view rendering and layouts. If these views/layouts have limited user interaction or simply serve static content, then implementing and using React may be more effort than it's worth. It's important to consider your development team's knowledge of React as well as the purpose / nature of your app before jumping into the hype that is React.js.