To sign up for our daily email newsletter, CLICK HERE
React.js is a JavaScript library that is increasingly becoming an issue at developers conferences, in social media and, last but not least, at Codecentric
I find the question particularly exciting: When does it make sense to use React.js for a project? And then:
- What problem does React.js solve for me?
- How mature is the library?
- What about the community, the documentation, etc.?
- Is the resulting code maintainable and easy to test?
- What does the integration into existing applications look like and how well can I integrate 3rd party artifacts?
- What tool support is available to the developer?
At the end of the article, I hope that you can classify React.js a little better and assess under which circumstances React is right for you.
How mature is React.js?
React.js was launched by Facebook in 2013. The library is also used by Facebook itself and is under a BSD license. This means that React.js can already be assumed to be ready for production. Although, as the switch from AngularJS 1.x to AngularJS 2.x has shown, the backing of a large corporation does not have to mean much.
What problem does React.js solve for me?
React.js is, similar to AngularJS, a client-side Javascript library.
However, the comparison is a bit slow.
What does React.js do differently in the view layer now?
From the point of view of the React developers, it is bad to have too many places in your application that can change the state of an application. Two-way data binding is one such example. In larger applications, it can be difficult to see where data changes originate. In a React.js application it is forced that there is only one (or a few) places where the state can be kept and changed. The content of this state can then be processed further immutable in the application.
React.js has a reputation for being fast, especially when compared to Angular, and for being able to handle larger amounts of data. This is due to the fact that, in essence, all state changes are kept via a virtual DOM implementation and thus the difference between two state changes can be recognized efficiently and only the result of this difference is transferred to the DOM. As a developer, however, you don’t notice anything about this.
Furthermore, a React application consistently consists of “components”, that is, independent application parts. React uses a hierarchical approach for this, whereby the state is often located in the root of my component tree.
It is therefore advisable to first divide the application into areas (components) on paper and to define the data flow before starting the coding. Check out the react admin template and bootstrap admin template for your next project.
When does React.js make sense?
React.js may not make sense in every situation in which client-side logic or SPAs are to be used. The investment in the toolchain and the type of thinking is perhaps still too far removed from the mainstream for that.
In my opinion, however, it makes a lot of sense in at least two scenarios. On the one hand, if you build a self-contained widget (and perhaps the league table) or if a lot of data is to be processed and displayed in the application, performance is an issue. In this context, it is also worth taking a look at FLUX in order to build larger applications with React.
