Abstraction Madness
In this post I talked about the wild abstraction in React. Now, don’t get me wrong, I still use React and I will, but as someone deeply embedded in the React ecosystem, I have noticed a trend that is hard to ignore - increasing complexity and layers of abstraction.
For someone who is new to programming, the way to go is to digest what you learn and gradually accustom your mind to the abstract. Non-programmers generally think much less abstractly because everyday life is concrete. Grocery shopping, going to school, cooking, spending time in a café are all concrete. Even though the digital solutions to these things are abstract, they are still concrete to them, as non-programmers don’t usually think about how these technologies work.
The only way to overcome this abstraction is to train your brain to deal with it. This is exactly what happens when you make projects. The more your projects solve real-life problems, the more abstraction skills you gain. For example, consider an admin panel. You’re performing a CRUD operation that somehow affects your main application. For a beginner, it’s challenging to abstract this because they might not even think about how to connect the two applications (panel and main app). Many frameworks were created to answer these kinds of abstractions. Each one claimed to make the web better…
My Journey
Like many frontend developers in the SPA era, I took my next step with React after completing HTML, CSS, and JS courses. Like many developers, I initially understood little because React was quite abstract at the time. Not wanting to waste time, I decided to give Vue a chance and managed to understand Vue’s logic. After a few Vue projects, I gave React another chance and yes, this time I was able to abstract sufficiently. I had understood React… at least well enough to undertake a project.
When I first started learning React, it was 2021. So, the cool thing was hooks. Everyone was using hooks. Of course, I used them too. useEffect for fetch calls, useCallback, useMemo, and React.memo to prevent rerenders. After a while, the noise-to-signal ratio in the component’s code increased significantly. For every 10 lines of actual component logic, I had to write an additional 10 lines for memoization to prevent React performance issues. Later, Redux for global state, TanStack Query for fetch calls, Formik or React Hook Form for form control, React DnD for drag and drop, etc…
The introduction of RSC (React Server Components) with version 13 of Next.js deepened this matter. This introduced another level of abstraction to consider! I won’t attempt to explain how RSC works as many do on Tech Twitter. My point is that the constant increase in the level of abstraction is providing a bad experience for developers. Especially for beginners, understanding and coping with these abstractions is very difficult. Concepts like hooks, HOCs, context providers, and now RSC, they turn this simple process of creating a UI into a nightmare.
Of course, the innovations brought by RSC are very important. Developing more performant and scalable applications with server-side components has become easier. However, the extra complexity brought by these new technologies raises the question: Is it really suitable for the requirements of the project?
Keeping up with this process and implementing such a level of abstraction in the world of React and Next.js is quite challenging. The important thing is to use these technologies correctly according to the needs of the project. That is, every time we add a new feature or layer of abstraction, we must consider whether it is really necessary, and whether it maintains the simplicity and understandability of the project.
For instance, the first framework I delved deeply into was React. With limited time (school, work, personal life), I couldn’t learn an ecosystem other than the one I was used to. Currently, I work from 9 to 6, try to learn new technologies in my free time, and also develop an app. Recently, I took two weeks to try a few different technologies. I read their documentation and tried authentication with simple-jwt after basic tutorials. The technologies I tried were: Solidjs, Astro, Astro + Solidjs, Svelte, Litjs, and Nextjs. My clear favorite was Svelte. Despite trying so many different technologies, I eventually chose Next.js because most job opportunities are there and I already write in React. I have followed all the changes in Next.js from the beginning, even though I have never written a full app with it. And believe me, it was exhausting.
Conclusion
Next.js took a step in the right direction with RSC, but it did so in a rather complicated manner. The changes were so significant that we had to relearn everything. There are still things about Nextjs I don’t understand. It’s always important to remember that as technology becomes more complex, so does the importance of using it correctly and maintaining simplicity when necessary.