Hello, I am Rian from the 6th Frontend cohort of Uteco, and I will be presenting on the topic of the legacy of React. React is a frontend UI library that was introduced by Meta in 2013. As you can see, it is currently the most popular among existing frontend UI stacks. Why has it become so popular? I would like to explain the reasons by retracing the footsteps of React. The agenda is as follows: I will divide the discussion into several units, starting with the period before the birth of React in 2013, followed by the era of class components, then the era of hooks, and finally, I will introduce the upcoming era of compilation. Shall we start by looking at the period before React's birth? Before React was born, around 2010, there was a remarkable advancement in JavaScript and web applications. With the emergence of Node.js, JavaScript evolved from being a language that only operated in web browsers to one that could also implement server-side functionality. Additionally, there were advancements in web APIs.

Various multimedia elements such as tags have been added, along with Geolocation, which allows for user location information, and the WebSocket API, which enables real-time communication. As a result, it has become possible to create various web applications with functionalities that were previously not feasible. Additionally, the role of the frontend, which used to passively display HTML created by the server, has begun to grow significantly. There has also been development in Single Page Applications (SPA). Previously, Multi Page Applications (MPA) were used, which required a full page transition even if only a part needed to be rendered, leading to page refreshes and flickering. In contrast, SPAs can render only the parts that need to be updated, allowing users to experience a smoother UI as if they are viewing a single page. Before React emerged, the SPA frameworks included AngularJS and Backbone.js, which had certain issues, such as the difficulty of manipulating the DOM.

I had to write complex code focused on structure, and managing state and data was difficult. Therefore, developers writing this code faced the problem of not being able to predict how the code would behave. However, when Meta introduced React in 2013, these existing issues were resolved. The difficult manipulation of the DOM was simplified by introducing a new syntax called JSX, allowing for the creation of intuitive, component-based code instead of complex, structure-focused code. Additionally, while managing state and data was challenging, React adopted a unidirectional data flow, making it easier for developers to predict state and data changes. With the emergence of React, developers could focus more on what to do rather than how to do it. In simpler terms, this means they could concentrate on solving essential problems in a straightforward manner. Next, we will discuss the era of class components.

Before talking about the era of class components, I would like to discuss the versions of React. Surprisingly, there was no version 1 through 14 of React. After the release of version 0.14 in 2015, it was immediately updated to version 15. The exact reasons for this are unclear, but it contributed to React being recognized as a mature and stable library. 

Now, returning to class components, they are much longer and less readable compared to the functional components we use today. But why did existing developers use class components? The reason lies in the lifecycle methods of class components. The lifecycle methods are closely related to React components, which go through a cycle of being created, updated, and eventually removed, much like living organisms. Each time this lifecycle progresses,

In order to trigger the lifecycle methods of a React component that is bound to it, developers who wanted to access the lifecycle of React components had no choice but to use class components. However, these class components had significant issues. As you can see, binding 'this' was difficult, and it was challenging to reuse the internal logic of these class components externally. To achieve reuse, developers used a pattern called Higher-Order Components (HOC), but this was not a clear solution either. It led to a problem known as wrapper hell, where components were nested within other components, significantly reducing code readability. To address the issues of class components, attention turned to functional components, which offered much better reusability and readability compared to class components.

However, there was no way to replace the lifecycle methods in class components. Functional components were merely UI components that rendered the props received from their parent. But developers found a solution to this problem, which will be discussed in the next chapter. We are now in the era of hooks. Developers created hooks to address the issues of functional components mentioned earlier. One of these hooks is called useEffect, which allows access to the React component lifecycle, similar to class components. In addition, hooks like useState, useContext, and useReducer emerged, enabling complex state management. With the addition of various hooks that provide different functionalities, functional components have evolved significantly. Now, I would like to explain the Fiber engine. This engine, known as React Fiber, is the core engine of React that was introduced in version 16. To summarize the Fiber engine in one line,

I can describe it as a smart assistant responsible for the React schedule. Before the application of the Fiber engine, React rendered based on a stack. As you can see, tasks were stacked one by one, and since the stack executes from the last added task, rendering occurred in the order of tasks 1, 2, and 3. However, there was a problem: if a long-running task is executed first and a task that needs to finish quickly is last, what happens? 

There is an example of reflecting text in an input. When text is reflected in the input, the user should see that text immediately. But if this task is at the very end, the user will have to wait a long time before seeing the text. This was a significant issue, but the Fiber engine resolves it as follows: first, it allows large subtitle units to be divided into smaller, detailed units. As you can see, the order of tasks can be modified according to their priority.

We have made it possible to achieve more effective rendering. Lastly, I will explain the upcoming era of compilation. The functional components I mentioned earlier also have a drawback, which is memoization. Memoization refers to the reuse of logic and components. In class components, methods are bound to instances and can be reused, but functional components do not inherently store components or functions. If you look at this code, the function called increment inside the component is not reused every time the component renders; instead, it is created anew each time. If you want to reuse it, manual memoization is necessary. By wrapping the increment function with useCallback, this increment will not be recreated. There are hooks designed for this kind of reuse, such as useCallback and useMemo. However, when we look at these hooks, we find ourselves in a dilemma: using these hooks every time is cumbersome, and we cannot easily determine when and where to apply them for efficiency.

However, with the upcoming React Compiler, these concerns may be somewhat resolved. The core feature of the React Compiler is automatic memoization. Automatic memoization means that the code is stored and reused automatically without manual intervention. According to the code you see, there is a component that receives a prop called friends. It iterates through each friend and renders a child component. Additionally, there is another child component below. Before the application of the React Compiler, even if part of friends changes, both the component and the child component are re-rendered every time. However, once the React Compiler is applied, only the changed parts of friends will be re-rendered, while all other components will be memoized and reused. Since they are not affected by friends, they can be reused. This means that only the parts related to the changed state will be re-rendered. However, the React Compiler is still in the experimental stage. The React Compiler first appeared in 2021.

However, it is still in the research stage. Fortunately, according to Andrew Clark, a core member of React, it could be introduced as early as the end of 2024. If the React compiler is implemented, it is expected to significantly enhance the convenience and efficiency for many developers. Now, let’s wrap this up. In my opinion, the reason React can have longevity is that it adheres to the principles of simplicity and reliability. React has solved the complex problems that developers face in various ways and has provided tools to use. React handles the tedious tasks, allowing developers to focus solely on problem-solving. Developers were able to write simple code using the methods I previously showed, and they could also write code focused solely on their objectives. As a result, this leads to the ability for all developers to write code that is understandable and trustworthy. Lastly, I was impressed by...

I will conclude the presentation by sharing a quote related to React. Thank you.

[10분 테코톡]리안의 리액트의 발자취

우아한형제들의 기술조직 이야기를 전하는 우아한테크입니다.

우아한형제들 https://www.woowahan.com/
우아한테크 Facebook https://www.facebook.com/woowahanTech
우아한형제들 기술블로그 https://techblog.woowahan.com