Learning React the hard way

Learning React the hard way

My regrets on learning React
Published March 6, 2022


React isn’t reactive
Virtual DOM isn’t fast
React isn’t all about JavaScript
Context API isn’t unsafe
UI library isn’t client side only

I thought React would be as reactive as its name, but it is not.


I thought JSX is all about JavaScript thus it’s pretty flexible. You can do cool things like function as children that is not possible in html or many other templating languages. Only when I was asked to do certain migration (e.g. angular to react) that involves heavy shuffling of markups did I realize that html interoperability sometimes may also be a concern.

Virtual DOM

I was told that virtual DOM is fast and real DOM is slow, but wait, doesn’t virtual DOM operates over real DOM? It turns out it still does and thus why svelte takes a different approach. However, real DOM never allows you to write declarative UIs.

Rendering Performance

I thought memoization techniques like shouldComponentUpdate , PureComponent , useMemo etc are good performance tuning techniques to avoid over rendering. But I was not been told that, in fine grained reactivity system, manual optimizations don’t always have to exist in the first place. So it becomes a mixed feeling when watching React w/o memo.

Context API

Context API once famous for being an “experimental” API, causing whatever uses it considered experimental as well. However, almost all popular libraries in the community had been using it and they seem to be fine still. Might worth noting, even the "non-experimental" version comes with caveat as well.

State Management

notion image
The state management is a myth, and in someway it resembles a lot with the styling solutions in React ecosystem (css-in-js, css modules and plain css etc). I dabbled around with different solutions for a while only to realize that react-query is more practical for most apps I am working with.

Functional programming

React reshapes modern web frontend with its declarative UI paradigm (rethinking best practice), and it embraces FP at heart. Stateless components, side effect segregation etc all good stuff. Then you may encounter immutability, and got amazed by the power of it since who doesn't like time traveling though? Followed by an unstoppable path of learning immutable.js, immer.js etc. At the end of day, I finally learned that JavaScript is a multi-paradigm language.

React Hooks

Hooks are great in terms of composibility but somehow deceitful as well. One thing is that a granular control over how state and effects can be composed for reusability does not mean the same granularity on rendering efficiency. The other thing is, for anyone who has been using it for a while, stale closure would not be unfamiliar for them.

Suspense / React Server Component

It does took me a while to understand why spinner waterfall was an issue, especially for people who start their frontend journey in the age of ajax / spa was the “default” way of building modern web apps. Until then I realized how big paradigm shift it is those modern web apps powered by spa frameworks comparing to traditional websites powered by say Rails. This is exactly where those meta frameworks like next.js or remix come into play. They exist to bridge the gap or cliff driven by the need of bringing rich interactivity from native apps(i.e. mobile) to web, almost forgot that the web actually speaks html instead of JavaScript.
There are a lot of other aspects to mention, but the learning is still in progress...
After all, those are all just what we call trade-offs right?