Is React a Framework?: A Question for Investment, Not Debt

The Message I Want to Convey Through This Article

• React is a rendering library.
• You cannot perfectly solve your problems with someone else's code. Technical debt related to this should always be kept in mind.
• You should clearly understand the concepts and characteristics of frameworks and libraries, and develop criteria for selecting appropriate solutions for the problems you face.

Overview

React is officially a library.

However, I often hear people questioning whether we should simply view React as just a library.

Let me first share my perspective: I would explain it as "React is a library." While making definitive statements isn't always a good habit, at least from my standpoint, I can say this with certainty.

Now let's examine this one step at a time.

Frameworks and Libraries

To determine whether React is a framework or a library, we first need to clearly understand the difference between the two.

Francesco Strazzullo, the author of Frameworkless Front-End Development, explains the distinction between libraries and frameworks as follows:

Frameworks call your code. Your code calls libraries.

I also believe this perspective clearly demonstrates the difference between frameworks and libraries.

Using a framework means that development follows the methods enforced by the tool.

To express this more clearly, a framework manages the application's control flow, and developers write code within the structure provided by the framework.

Conversely, with libraries, the developer manages the control flow and calls the library within it—this is a more distinctly expressed difference.

The diagram above illustrates this visually.

What is "Framework's Way"?

Since I'm learning based on the book, I can't leave out the author's perspective.

If you're using 'Framework's way' when handling tasks, it can be considered a framework.

This is the criterion for judging frameworks that the author presents in the book.

What is Framework's way?

This was a new concept for me when I encountered it through the book.

Simply put, it refers to things that are enforced to use a tool. Using Angular as an example:

1. Language: TypeScript is the de facto standard in the Angular ecosystem.
2. Dependency Injection: For elements to communicate in an Angular application, they must use the dependency injection mechanism according to their type.
3. Observables: Angular is designed based on RxJS, a library for reactive programming that uses Observables instead of the standard Promises.

Some of the elements above are not necessarily required, but they are used as de facto standards by community users.

Ultimately, Framework's way means that regardless of whether something is a framework or not, certain rules are enforced and universalized by community users as de facto standards.

React from the Framework's Way Perspective

Looking at React from this perspective, it can be said to follow Framework's way.

You can manipulate the DOM in an imperative style like Vanilla JS using React.createElement or class syntax.

However, the commonly used approach in current React is the declarative style based on JSX and similar technologies.

Additionally, the recent React community recommends using the functional approach.

As a result, it has become common to use the declarative style with useState, useEffect, useRef, and so on.

Let's look at some code to better understand this perspective.

If you're a React user, the imperative style might feel unfamiliar.

However, it's a perfectly valid working approach. We've become accustomed to the methods recommended by the community and official documentation, which is why this coding style might seem somewhat awkward.

This is exactly what Framework's way means. Not a framework, but a de facto standard method used like a framework by the community.

So, Is React a Framework?

If you're using 'Framework's way' when handling tasks, it can be considered a framework.

According to the author's criteria, it could be called a framework.

However, my perspective is slightly different.

I believe frameworks should be evaluated according to the criteria confirmed in Frameworks and Libraries.

In reality, with React, you can write only a portion of your code in React within a code flow written in vanilla JS.

In other words, you can execute React within the flow of code written by the developer.

If you define React as a framework and develop according to React's flow as per the above criteria, you might inadvertently lose flexible thinking.

Furthermore, every tool has problems it aims to solve, and there's a possibility of missing that essence.

Therefore, I believe viewing React as a library is a better approach.

Technical Debt

Some might question why they need to know this distinction.

The reason I've explored this deeply is that using a framework is not free.

The concept of "free" here doesn't mean using it without paying money like open source. It's about the additional costs incurred by using frameworks from a maintenance perspective.

The author cites Ward Cunningham's Technical debt as an example.

The messier the solution you choose, the more technical debt increases.

Using a framework without fully understanding it is like carrying the risk of various errors and modifications during the maintenance phase.

This may not be visible on the surface, but it's something that must eventually be repaid.

And of course, interest accrues on debt.

As a simple yet extreme example, think about the cost of replacing a framework used at the beginning of a project with another framework versus replacing a framework that has been used for 10 years.

The latter requires significantly more cost than the former.

Technical Investment

Someone else's code cannot be the optimal way to solve your problem.

The author conveys this opinion citing technical debt. At the same time, they also present the concept of technical investment.

While it would be nice to implement everything yourself, this actually goes against the nature of software.

In my personal opinion, the biggest factor that makes the software industry different from other industries is that it can be replicated.

Can't you copy any file or software with just CTRL+C / CTRL+V?

This also implies the characteristic of being reusable.

Just as you take out loans when buying a house or starting a business, technical debt is not necessarily a bad thing.

If debt can be managed appropriately, it can actually become an investment.

Conclusion: What to Focus On

The perspectives of technical debt and technical investment suggest that when adopting frameworks, we should consider them from a cost perspective.

Ultimately, the key is to introduce appropriate and fast solutions with reasonable justification to solve problems.

The reason I posed the seemingly odd question "Is React a framework?" and established criteria for judgment in this article was an approach from this perspective.

Furthermore, to make clearer judgments, I've started examining the source code of libraries/frameworks and sometimes attempting to implement things directly.

While it's certainly important to be skilled with tools, I believe learning fundamental elements is necessary to avoid being absorbed by the tools and to develop appropriate judgment criteria and usage for the problems we currently face.

I hope this article has been of some help to other developers as well.