Learning about React
Thoughts on the React framework, before jumping in and writing it myself. Virtual DOM, performance, concerns I have, and some resources.
The idea of the virtual DOM (not shadow DOM) is certainly innovative, but its implementation is what made me hesitant to jump on board. Components are heavily wrapped in React syntax, even when written in JSX, and the ideology is so orthogonal to web components and the other solutions out there. But I guess that’s what makes it exciting. Unfortunately, it is exciting for developers, but adds one more layer of complexity for designers hoping to be involved in coding.
So far, the best resource I’ve found for understanding the framework is Josh Haberman’s React Demystified. It provides a solid explanation:
Modifying and querying the DOM is a huge performance bottleneck, and React embraces an approach that eschews this without sacrificing expressivity. It presents a well-designed object-oriented interface, but everything underneath the hood has been crafted with the eye of a pragmatic functional programmer. It works by generating a virtual version of the DOM and, as your application state evolves, it diffs changes between the virtual DOM trees over time. It uses these diffs to make the minimal set of changes required on the real DOM so you don’t have to.
Critically, a function
shouldComponentUpdate does a diff, and only modifies the DOM if necessary.
Also from that article is this diagram:
Through the virtual DOM, React brings to the forefront a paradigm beyond data-binding, i.e. throwing out and recreating a bit of DOM each render. Perhaps counterintuitively, this is faster. It also simplifies concerns in event-driven flows, and makes it easier to reason about how changes in state will affect performance.
React doesn’t replace other MVC frameworks, as it doesn’t tie the web app together (it only claims to be the V in MVC). Instagram uses it 100%, and Facebook and others rely on it heavily. In a backend-heavy app, React is great. I think there’s been a shift back toward data-processing on the server, and a focus on only certain intensive processes running on the client - e.g. rendering, basic interactions and business logic. Particularly as businesses further guard their data.
React’s performance can be dramatically improved using an Immutable Object library, like Om or Facebook’s Immutable, where it does not need to traverse the whole element to check for eqaulity, but instead just checks for reference equality. But that’s another story, which Facebook is still writing.
Coupling to the framework - React components must be written in a React-specific syntax and take a bit more effort to refactor away from the framework. It also makes it a bit more complicated for designers to get involved in coding.
React is a view library. It makes no opinions about your model (though it benefits from an immutable object library). My concern is that with its modularity, it may hinder complex app-wide business logic.
It makes it difficult to interact with the DOM. It is also difficult to information from the DOM, so it is best for apps with simple user interactions. It is often not realistic to assume your entire app will consist of components, and interacting with the DOM (rather than programmatically affecting the virtual DOM) can be tricky - especially if you’re still using something like jQuery. React provides a resource for working with the browser
I’ll be writing a few components to actually play with it soon, and see how I feel about some of these concerns - at least those possible in a simple sandbox.