Frequently modifying and haunting the physical HTML DOM is slow and a potential performance bottleneck for non trivial applications. React tries to solve this issue by introducing a virtual JS DOM representation. Using this, it is perfectly able to keep track of state when rendering UI components. When state changes it labels appropriate components as changed. At the end of the event loop, React looks at all changed-marked components and re-renders them batch-wise. This means only one physical DOM update during the event loop, which also just includes the minimal set of required changes. Using this technique React allows for super efficient and fast UI rendering. That’s basically what React is, a virtual DOM equipped with a nice API that lets you build hierarchical components, more on that later.
If you treat the browser as a remote rendering engine and stop treating it as a place to query and store crap, everything gets faster. Sound like something familiar? Yeah, computer graphics programming.
React and Web Components
An interesting question is whether React and Web Components can survive together or even partner up and if so, how? React basically provides a virtual DOM with rendering capabilities and Web Components is an umbrella term for an emerging group of specifications that describe new API primitives in the browser. It’s obvious that the philosophy of rendering components is quite different. Web Components embrace the physical HTML DOM and build upon that by extending it. React relies on the "virtual" JS DOM.
Nevertheless there are also things that they share. Shadow DOM for example, which is part of the Web Components standards, addresses the HTML DOM encapsulation problem. It’s kinda funny, that this concept of hiding DOM functionality and putting it into its own scope in the "shadow" of a physical DOM node is something that (somehow) aims in the same direction. React only goes one step further and totally leaves the HTML DOM on its own. I can imagine one could pair those two techniques and use Shadow DOM as target for React rendered components.
Those components could use Custom Elements, also part of Web Components, as their entry points. React components encapsulate UI and UI logic which apparently belong together. This is also something Custom Elements strive for.
One difference where React components really shine is composeablity and interoperability – it’s providing this by embracing the nature of DOM cascade! Child components, in particular, can receive immutable properties »props« from their parent. Such an relationship is called ownership. Components that set props of other components are owners but not necessarily direct parents in terms of DOM structure. This data flow (one-way data binding) lets you elegantly compose components and build reusable widgets.
Isomorphic JS components
Web Components do not really offer a good way to render them server side. One thing that Custom Elements provide to prevent FOUC is the CSS pseudo class
Having this abstract, virtual DOM already running on the server, why not make it even a browser built-in and let the browser care about physical DOM updates? Building a js-based DOM according to the "real" HTML DOM and providing some effective rendering/update algorithms sounds like a perfect task for the browser. I’m not sure if this is even possible, but at least it’s an interesting reasoning.
Taking a step back and fundamentally rethinking rendering approaches is really inspiring and a thing the whole web can benefit from. When you first look at React it may feel odd, especially the JSX part of it. But I encourage you to take the time and fiddle around, it’s really worth it. Be open to its new techniques, the work Facebook’s engineers did here should really not be under-appreciated. I think its concepts totally have the potential of influencing future web standards.