Hooks Burnout: Why I Am Wishing for the Return of Class Components

This is the story of a seasoned Front End Developer's journey with React Hooks, exploring the challenges and frustrations leading to Hooks burnout.

Have you ever experienced that moment when something you once loved started to feel overwhelming? As a seasoned Front End Developer with over a decade of experience, I found myself in a similar situation with React Hooks.

For years, I've been immersed in the world of React, witnessing the transition from class components to the functional paradigm. Initially, Hooks seemed like a breath of fresh air, offering a simpler alternative to complex logic-sharing solutions.

However, as time went on, I began to feel the weight of writing performant code with Hooks, and the recent talks by David Khourshid and Xuan Huang only deepened my frustration. In this article, I'll delve into the concept of Hooks burnout, the challenges it brings, and the concerns I share with other experienced React developers.

Unlike the class component days, where performance concerns were relatively manageable, Hooks introduced a new level of complexity. To achieve a smooth user experience, we often find ourselves littering our code with useMemo and useCallback, constantly synchronizing the dependency arrays.

While these optimizations are necessary, they also contribute to what I call DX ruin - a decline in Developer Experience.

Of course, one might argue that we could simplify our code by passing down raw functions everywhere, but doing so compromises the user experience. It's frustrating to work towards performance at the expense of code cleanliness. The common advice is to split up logic into smaller hooks, but even that approach raises concerns.

In the days of class components, I don't recall ever grappling with dependency arrays as I do now. This ongoing struggle with Hooks burnout has even made me yearn for the simplicity of Vue's computed properties, which effortlessly compute derived states without the need for a dependency array. Now, some might suggest that we don't have to optimize everything prematurely. While that's true, the functional nature of React components compels us to be constantly aware of performance considerations.

Hooks force us to navigate the intricacies of re-renders and memoization opportunities, often resulting in more work than we had with class components. Interestingly, even the React team acknowledges these challenges, as they are actively exploring a way to transpile useMemo and useCallback on everything in a future version of React. This acknowledgment speaks volumes about the current state of Hooks and their imperfections. It's important to note that many of these complaints arise not only from poor hook usage or code smells but also from the lack of consistent educational material.

Even the official React.js documentation doesn't always provide the clearest explanations for most hooks (which is getting better with the new arrival of react docs). Take useEffect, for example. While it's described as a hook for performing side effects, it makes more sense to place side effects in event listeners to maintain reactivity and simplicity. This inconsistency in messaging adds to the confusion and compounds the challenges faced by developers.

Conclusion

In no way am I denouncing Hooks; I do appreciate their power and flexibility. However, after using them extensively in complex React applications for various companies, I feel compelled to express my frustrations and concerns. React developers of varying experience levels and backgrounds may hold differing opinions on Hooks, but the common theme of burnout is worth exploring. Hooks burnout is a real phenomenon experienced by many, and it highlights the need for continued improvement and support within the React community. Let's acknowledge the challenges, seek solutions together, and strive for a future where Hooks empower us without overwhelming our development experience.