Thoughts on React.js
Last week, my cutting-edge web technologies class had the luxury of being lectured by one of the core contributors to the React.js project: Pete Hunt.
What is it?
Or as React’s website simply puts it:
- There’s a lot of interleaving in the code. When tinkering in frameworks like Ember.js and Angular.js, you could find yourself breaking abstraction barriers and accessing properties of certain elements in order get the correct interaction you’d like to see in your user interface.
- You’re unfortunately using string literals for accessors and directives. This has some poor implications on testing, especially in static type checking.
- The overhead of KVO typically grows linearly with the amount of data you’re modeling. However, although most web applications will have a lot of data modeled, you’ll typically only render a few hundred elements in the view for the user to interact with. This could imply that KVO will waste resources on tracking stuff that doesn’t necessarily matter.
Instead of keeping track of every single change as a chain of events, React uses the following model:
- React tracks snapshots of the entire DOM at a particular time
- React renders the page in a virtual DOM
- React takes the diff between the client’s DOM and the virtual DOM
- React applies the changes to the elements that have changed
What do I gain if I use React?
React helps you to properly separate UI responsibilities from controller logic. Often times when developing in KVO-based frameworks, it’s difficult to enforce these abstractions properly. You can find yourself mangling accessor interactions in the view, the model, and/or even the controller. React helps enforce an abstraction that prevents interleaving responsibilities.
Another fundamental advantage of React is that its data processing model scales well with large amounts of modeled data in a typical web application. The typical web application doesn’t display all it’s modeled data in the DOM; most commonly the top 10 or top 100 is presented in some interactive fashion. Traditional KVO-based frameworks have significant overhead while tracking changes (linear to the amount of data you have) and can have negative memory performance implications. This is especially detrimental to mobile devices which will simply crash if memory is over-utilized.
Okay, but what do I lose?
React is a great framework to use for a typical web application with a ton of changing data and a subset of visualizations. That being said, React isn’t perfect for everything.
React uses a lot more CPU to perform its diff between the virtual DOM and the current DOM. This has some major performance implications on realtime re-rendering of a lot of nodes in the DOM. If a lot of changes are happening in the DOM in rapid succession, the application will constantly be utilizing the CPU to perform these diffs – which could result in user interactions that aren’t as smooth as one would like.
The touted memory performance analysis of React, React’s overhead grows linearly with the size of your view, can also have negative performance implications on some unique use cases. In a web application that renders tons of nodes in the DOM, this would significantly cause the web application to at least double in memory usage to just perform a diff with the virtual DOM (since all the nodes need to be rendered in the virtual DOM).
An example of an application that would perform extremely poorly is an interactive visualization of large datasets in which all of the data needs to be represented multiple times in the DOM. Not only could realtime visual interactions be slowed down by the virtual DOM diffs, but also the memory requirements in rendering a virtual DOM for visualizing all the data could prove extremely costly in memory requirements for the application. Applications like this might be better off utilizing D3.js in organizing UI interactions.
Pete’s lecture on the benefits of React have really helped inform me on when I should be using React for a web application project. I haven’t done much programming with React, but I foresee it being my “go to” framework for many of the common web applications I’ll end up developing.
Credits to Andrew Fang and Erica Yin on helping me write this post.