React

React

서론

이 이미지는 그냥 웃기게생겨서

리액트 써도 좀 알고 쓰자!!! 의 일환이다

리액트로 토이 프로젝트 몇번 해 보면서 진지하게 리액트의 원리와 동작 과정에 관해 고찰해본 적이 몇 번이나 되는가?

나는… 없는 듯 하다… 가상 돔을 만들어서 어쩌구….. 이것밖에 모른다 (부끄)

리액트 쓰는 거 좋고 리액트로 프로젝트 다 좋지만 기왕 쓰는거 지피지기면 백전백승이라는데 한번 알아보고 넘어가자

리액트 카테고리에 글을 이렇게 많이 적어놓고 이제 와서 리액트의 동작을 처음 알아보는 것도 개그 포인트이다 (하하하)

리액트 소개

리액트가 뭔가요

싱글 페이지 애플리케이션을 제작하는 데에 초점이 맞춰져 있는 자바스크립트 라이브러리이다

Vue도 프레임워크고 Angular도 프레임워크고 Svelte도.. 그래서 리액트도 프레임워크일 것 같은 느낌이 강하게 오지만 프레임워크는 아니다

어디 가서 컴포넌트 단위로 개발할 수 있는 게 장점이에욧!!! 하면 안 된다 Vue도 컴포넌트 지원한다고 한다 😕 (이게 장점인 줄 굳게 믿고 있던 사람)

페이스북 (지금은 메타) 에서 만들었다는 사실로 유명하다

장점

• 라이브러리인 만큼 JS 문법을 활용하는 경우가 매우 많기 때문에 나는 자바스크립트를 어느 정도 해 봤는데 새로운 문법을 배우고 싶진 않다… 하면 리액트가 적합한 대안이다
  • JSX이 약간의 변칙적인 문법이긴 하지만 HTML 태그를 주구장창 작성해 봤다면 HTML 태그에 속성을 주듯이 손쉽게 사용할 수 있다
  • Vue는 전용 문법이 따로 있어서 자바스크립트를 해보고 왔어도 Vue 문법을 또 익혀야 하기 때문에 쬐끔 부담스럽고, 그 쉽고 간결하다는 Svelte도 결국에는 HTML 태그스러운 코드에 약간의 자바스크립트를 비벼서 드셔보세요 느낌의 문법을 새로 익혀야 한다
• 가상 DOM을 사용하여 실제 DOM 접근 횟수를 확 낮췄고, 렌더링 횟수도 극적으로 줄어들었다
  • 원래대로라면 데이터가 바뀔 때마다 실제 DOM을 매번 접근하여 조작하기 때문에, 데이터 개수 또는 데이터의 변화량이 많을 수록 DOM이 반복적으로 조작되면서 렌더링 횟수가 매우 늘어난다
  • 리액트에서는 가상 DOM을 사용하여 데이터 변경 전 / 후를 비교하고, 변경된 부분만 실제 DOM에 적용하기 때문에 레이아웃 계산 횟수가 줄어드는 것이다
• 데이터가 단방향으로만 흐르기 때문에 (부모 → 자식) 데이터 흐름 제어가 수월하다
  • 데이터가 여기로 갔다 저기로 갔다 한다고 생각하면 신경써야 할 점이 배로 늘어날 것
  • 데이터의 변화로 DOM을 갱신할 때 전체를 다 갱신할 필요 없이 일부 요소들만 바꿔주면 되므로 효율적이다
  • 자식에서 부모로 데이터를 전달하는 것이 번거롭기 때문에 코드 작성자 입장에선 조금 단점같이 느껴질 수도…
• 알아두면 나중에 모바일 앱 개발도 할 수 있다 (?)
  • React-native가 리액트 문법을 기본 골자로 하므로 웹 개발 좀 익숙하다 싶으면 앱 개발도 시도할 수 있다
  • 플러터처럼 프레임워크 하나로 안드로이드 - ios 둘 다 지원이 가능해 편리하다

https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue.js%2Cangular%2Csvelte%2Cangularjs%2Cvuejs3

• 압도적 이용자 수에서 기인한 거대한 커뮤니티
  • 위의 사진은 Stack overflow에 올라오는 질문에서 언급되는 비율이라고 한다
  • 2022년 현재 두 번째로 비중이 큰 Angular보다 두 배 이상 자주 언급되는 것을 볼 수 있다
  • 라이브러리나 관련 자료 찾다 보면 커뮤니티 규모 무시 못한다…. 왠만한 자료가 이미 다 나와 있고, 이거 라이브러리 있으면 편하겠다 싶은 게 다 라이브러리로 npm 어딘가에 존재한다

단점

• MVC / MVVM 등의 패턴을 전제하는 Angular, Vue 등의 여타 프레임워크와 달리, 뷰에만 온 힘을 쏟은 느낌
  • 기본적으로 페이지 전환 기능을 제공하지 않아 react-router이 필요하다
  • API 통신도 지원하지 않아 axios, fetch 등의 라이브러리나 모듈을 사용해야 한다
  • 전역 상태 관리도 Redux, Recoil 등의 외부 라이브러리를 가져다 써야 한다
  • 이처럼 리액트 자체만으로 구현할 수 없는 (또는 매우 힘든) 기능들이 있어 추가 라이브러리의 힘을 자주 빌려야 한다
• 자바스크립트 문법을 잘 모르면? 힘들다
  • JSX를 사용한 렌더링 부분을 제외하면 로직을 전부 자바스크립트로 작성해야 한다
  • 자바스크립트를 하나도 모르지만 웹 개발은 하고 싶다면… 러닝커브가 비교적 낮다고 하는 Vue를 알아보는 것이 좋겠다
• 자유도가 높은 만큼 협업할 때 살짝 번거롭다
  • Vue는 자체 문법을 사용하니 어느 정도 코딩 스타일이 맞춰지는 편이지만, 리액트는 기본이 자바스크립트이므로 코딩 스타일도 천차만별이다
  • 높은 자유도 때문에 오히려 지름길을 놔두고 종종 돌아가는 경우도 생긴다
• 공식 문서 업데이트가 느리다
  • 함수형 컴포넌트가 대세가 된 지 좀 지났지만 아직도 공식 문서 예제 중 클래스형 컴포넌트만 되어있는 것이.. 종종 있다
  • https://ko.reactjs.org/docs/state-and-lifecycle.html 상태와 생명주기라는 굉장히 중요한 주제에 관련된 문서임에도 예제들이 아직 클래스형 컴포넌트로만 되어있다 (💩)

그 외에도 (자꾸 Vue랑 비교해서 리액트에겐 조금 미안하지만) Vue가 프레임워크임에도 불구하고 더 가볍고, 페이지 로딩 속도가 빠르다고 한다

Vue를 한 번도 안 써봐서 체감하긴 어려운데 궁금하긴 하다

곁다리: 프레임워크 / 라이브러리

프레임워크는

• 기능 구현에 집중할 수 있도록 뼈대를 제공해준다
• 내부적으로 알아서 판을 깔아주고 기능의 흐름 등을 제어해 주므로, 개발자는 그 위에서 기능만 쏙쏙 개발하면 된다
• 베이스가 되는 언어 (Vue - JS, Django - Python 등) 뿐만 아니라 독자적인 문법이나 컨벤션 등도 별도로 공부해야 하는 경우가 많다
• 설계 패턴들이 이미 상당수 적용되어 있다 (예시로 Angular 앱은 MVVM 패턴을 적용받는다)
• 틀이 이미 어느 정도 짜여져 있으므로 라이브러리만 가지고 개발하는 것보단 자유도가 조금 떨어진다 (상대적으로)
• 프레임워크 설치 및 세팅을 해줘야 하기 때문에 컴파일을 통해 결과물을 압축하여 내보내기 전까진 프로젝트 전체 용량이 무겁다
• 우리가 자주 사용하는 Express, Express를 발전시킨 NestJS도 웹 서버 프레임워크이다
• 디자인에 종종 사용되는 부트스트랩도 프레임워크이다

라이브러리는

• 개발을 할 때 ‘이거 미리 만들어 놓고 가져다 쓰기만 하면 편할 것 같은데??’ 싶은 도구들의 집합이다
• 개발자의 반복 작업을 어느 정도 줄여주고, 자칫 어떠한 기능 구현 때문에 방대해질 수도 있는 코드를 압축해 준다
• 입맛대로 필요한 기능만 쏙쏙 설치하여 사용하면 되므로 프레임워크에 비하면 덜 무겁고, 더 자유도가 높다
• React는 프레임워크같아 보이지만 라이브러리라고 한다
• 차트를 쉽게 그리게 도와주는 Victory.js, 자바스크립트에 편의성을 더해주는 lodash 등이 라이브러리이다

조금 이상한 비유일 수도 있지만 굳이 (?) 들어 보자면

• 프레임워크는 방의 개수, 방의 배치, 벽지의 색상, 바닥재 종류, 화장실 개수, 지붕 색상 등을 정해주면 그에 맞추어 집을 뚝딱 만들어 주며 사용자는 가구 배치에만 집중하면 되는 주택 건설 시스템
• 라이브러리는 직접 시멘트를 굳혀 벽돌을 굽고 하나하나 쌓아올릴 때 쓰는 도구들 (삽, 트랙터, 가마 등)

이라고 생각한다

사실 요즘 구분이 크게 의미는 없고 그냥 프레임워크 / 라이브러리 개발자 측에서 ‘이건 프레임워크에용' 하면 프레임워크고 ‘이건 라이브러리에용’ 하면 라이브러리라고 받아들이면 된다고 한다?

리액트의 특징

가상 DOM (Virtual DOM)

DOM

https://blog.chichoon.com/418

html DOM

DOM이란 html 태그들을 파싱하여 자바스크립트 등에서 사용할 수 있도록 만든 트리 구조 모델이라는 것을 옛날 포스팅에서 적었었다

부모 - 자식 노드, 형제 노드 관계 등을 DOM이 트리 형태로 가지고 있기 때문에 querySelector 등을 이용하여 각 요소를 찾아 접근할 수 있는 것이다

또한 이 DOM 트리와 스타일 트리 (CSSOM) 를 합쳐 화면에 실질적으로 표시되는 요소들을 담고 있는 렌더 트리를 그리게 된다

따라서 만약 DOM 트리에 변화가 생기면, 렌더 트리 또한 다시 그려져야 한다

리액트, 앵귤러 등의 프레임워크 (또는 라이브러리) 대두 전까지는 브라우저에 그려지는 DOM 그 자체를 조작해서 화면을 다시 그려주었으며, 만약 여러 요소에서 변화가 발생하면 변화의 개수만큼 렌더 트리가 새로 생성되었다

렌더 트리를 한 번 그리는 데에 꽤 많은 연산과 메모리를 필요로 하며, 트리가 거대하면 거대할 수록 렌더링 속도가 느려지면서 여러 오류가 발생하고 사용자 경험을 꽝으로 만든다

 

가상 DOM

그렇다면 화면에 직접 리렌더링하는 대신 실제 DOM이 아닌 어딘가에 변화를 전부 기록해놓고, 이를 한번에 업데이트하면 연산 횟수를 줄일 수 있지 않을까? 라는 아이디어에서 출발한 것이 가상 DOM이다

마트에 여러 번 방문해서 필요한 물건을 따로따로 구매하는 것보다, 메모장에 구매할 물건 리스트를 기록해둔 뒤 한 번만 방문해서 물건을 전부 사들고 오는 것과 비슷한 느낌이다

가상 DOM은 실제 DOM을 어느 정도 추상화시킨 형태의 모델 객체로, 실제 DOM을 직접 조작하는 대신 가상 DOM에 노드의 변화를 기록해둔 뒤 나중에 한번에 동기화한다

또한 가상 DOM과 실제 DOM을 비교하여 바뀐 부분만 적용하고, 변경되지 않은 부분은 놔두는 식으로 불필요한 추가 연산을 방지할 수 있다

React가 처음으로 가상 DOM 개념을 도입하였고, 이후 나온 Vue 또한 가상 DOM을 사용하여 템플릿 업데이트를 적용한다고 한다

JSX

자바스크립트에 XML을 작성할 수 있는 새로운 문법이다

리액트 프로젝트에 사용되므로 VSCode 등의 IDE에서 JSX 파일의 아이콘을 리액트 아이콘으로 출력해 주기도 한다

리액트 개발 전용 코드라 당연히 브라우저가 이해할 수 있을 리가 없으므로 (…) 바벨을 사용하여 일반 자바스크립트 (DOM element 형태) 로 트랜스파일링 해야한다

HTML 문서를 만들고, 거기에 script 태그로 자바스크립트 파일을 불러오거나 함수를 호출하고… 할 필요 없이 자바스크립트 코드 안에서 HTML 태그 작성까지 할 수 있으니 간편하다

다만 뷰와 로직을 신중하게 분리하고, 컴포넌트를 잘 쪼개지 않으면 파일 하나의 덩치가 기하급수적으로 불어나게 하는 원인이기도 하다…

 

특징

// 정상 코드
function foo() {
    return (
        <div>
            <span>안뇽</span>
            <span>잘자</span>
        </div>
    );
}

// 잘못된 코드
function foo() {
    return (
        <span>안뇽</span>
        <span>잘자</span>
    );
}

JSX 내에서 작성하는 XML 코드는 가상 DOM 트리에 반영되므로, JSX 코드 또한 하나의 서브트리 (부모 - 자식) 로 이루어져 있어야 한다

JSX 안의 XML 영역은 무조건 부모 요소 하나로 감싸져 있어야 한다 (= 서브트리에서 최상단 루트 노드가 되는 요소가 존재해야 한다)

부모 요소를 추가하고 싶지 않은 경우, 빈 요소인 Fragment (<></>) 를 사용해서 감싸주면 된다

 

function foo() {
    const list = [1, 2, 3, 4, 5];
    return (
        <ul>
            {list.map(v => <li><span>{v}</span></li>)}
        </ul>
    )
}

XML 코드 중간에 {} 괄호를 통해 자바스크립트 표현식 또한 작성할 수 있다

표현식에 해당하는 것은 함수 호출, 메서드 체이닝, 각종 연산자 등이 있다

문 (Statement, 반복문, 조건문 등) 은 사용할 수 없다 (콜백 함수 안에서는 사용 가능하긴 하다)

반복문은 map이나 reduce 등의 메서드로 대체하고, 조건문은 삼항연산자나 &&, ||, 옵셔널 체이닝, 널리시 연산자 등으로 대체하면 된다 (함수형 프로그래밍을 지향하는 느낌)

ejs처럼 HTML 코드 내에 자바스크립트를 삽입할 수 있다는 점에서 잘만 사용하면 코드가 훨씬 간결해지고 원하는 요소만 쏙쏙 렌더링할 수 있게 되지만, 그렇다고 로직을 전부 때려넣게 되었다간 꽤나 보기싫은 코드가 되므로 주의하자

단방향 데이터 흐름

function Child({ name }) { // props
    const [age, setAge] = useState(20); // state
    return (
        <>
            <span>{name}</span>
            <span>{age}</span>
        </>
    );
}

function Parent() {
    return (
        <div>
            <Child name="chichoon" />
        </div>
    );
}

컴포넌트는 두 가지 종류의 데이터를 다룰 수 있는데,

• props
  • 함수에서의 인자로 받아오거나 JSX 문법으로 속성 (attribute) 처럼 받아올 수 있는 값이다
  • 부모 컴포넌트에서 자식 컴포넌트로 내려주는 값이다
  • 컴포넌트 내에서 수정할 수 없다 (변하지 않는 값)
• state
  • 컴포넌트 내부에서 선언하며, setState() 함수를 통해 값을 바꿀 수 있다
  • state를 props로서 하위 컴포넌트에 내려줄 수 있다
  • 컴포넌트가 수정할 수 있다

state는 컴포넌트 내부에서 선언되고 변경 및 사용되는 값이고, props는 부모에서 자식으로만 내려줄 수 있다

우리는 여기서 데이터가 부모 → 자식 방향으로만 흐른다는 것을 알 수 있다

이처럼 데이터가 한 방향으로만 일관적으로 흐르는 것을 단방향 데이터 흐름 이라고 하고, 폭포처럼 상위 노드에서 하위 노드로 데이터가 떨어지는 방식을 Flux 디자인 패턴이라고 한다

 

피치 못할 사정으로 자식 컴포넌트에서 부모 컴포넌트의 상태값을 변경해야 한다면, Lifting State Up을 이용한다

부모 컴포넌트에서는 props로 상태값 그 자체 대신 상태를 변경해주는 콜백 (setState()) 을 넘겨주고, 자식 컴포넌트는 이 콜백을 이용하여 상태값을 아래에서 위로 바꿔주는 방식이다

depth가 너무 깊어질 경우에는 전역 상태관리 라이브러리를 사용하는 것도 하나의 방법이다

그 외 특징들

• 컴포넌트 단위의 개발
  • JSX 형식의 컴포넌트로 페이지를 요소별로 분리하여 개발이 가능하다
  • 레고 블럭을 만들고, 이 레고 블럭을 이어붙여 큰 작품을 만드는 느낌의 개념이다
  • 요소를 잘게 쪼갬으로써 관심사 분리가 되므로 코드가 한층 간결해지고, 유지보수에 용이해진다
• Next.js를 통한 SSR
  • 이건 Next.js의 특징인 것 같긴 한데 (ㅋㅋㅋ) 서버사이드 렌더링을 할 수 있다
  • 서버사이드 렌더링을 통해 검색 엔진 최적화 (SEO) 와 빠른 페이지 렌더링이 가능해진다
  • 검색 엔진 최적화는 곧 검색 결과 창에서의 웹 사이트 노출량 증가로 이어진다
• React Native
  • 리액트의 문법을 그대로 사용하여 IOS, Android 둘 다 한번에 호환 가능한 어플리케이션을 만들 수 있다
  • 자바스크립트를 사용하므로 Flutter - Dart와 같이 추가적인 언어를 공부할 필요가 없다

결론

전에는 리액트를 별 생각 없이 사용했었지만 이제는 조금 생각하면서 사용할 수 있게 되었다 (??)

가상 DOM, useState나 useEffect 등의 훅, 생명주기 등은 직접 구현해보면서 공부해볼까 싶다

번외: 프론트엔드의 역사

1. 태초에 HTML이 있었다

팀 버너스 리에 의해 웹이 고안되면서, 웹에서 주고받을 문서의 표준 (HTML) 이 같이 등장했다

이 때까지만 해도 그냥 정적 데이터만을 보여주는 용도가 끝이었다

사용자와의 인터렉션? 그런 거 없다 사용자는 그냥 서버가 보내주는 데이터만 읽어!!!!

2. PHP, ASP, JSP

Personal Home Page tools (지금은 PHP: Hypertext Preprocessor의 약자로 바뀌었댄다)

Active Server Page

Java Server Pages

세 개의 서버사이드 스크립트 언어의 등장으로 사용자와의 상호작용 또한 가능케 됐다

이제 사용자가 요청을 보내면 서버에서 적절한 데이터를 HTML에 잘 싸서 보내준다

다만 사용자가 버튼을 클릭하면 데이터를 새로 받아와서 현재 페이지를 수정해 주고.. 이런 방식이 아니라, 사용자가 요청을 보내면 서버에서 응답으로 페이지를 보내고, 이 페이지를 브라우저에서 다시 띄워줘야 했다

지금은 서버에서 보낸 데이터를 클라이언트 사이드에서 처리해서 현재 페이지에 바로 출력할 수 있지만, 그 때는 그랬다… 새로고침이나 페이지 이동이 강제되는 시대였다

3. Javascript의 등장

사실 Javascript와 PHP, ASP, JSP는 상당히 비슷한 시기에 등장하긴 했다

자바스크립트 또한 위의 세 언어들처럼 서버사이드에서 사용될 언어였지만, 자바의 하위호환이라는 느낌에 성능문제 때문에 서버에선 쫒겨났고, 마이크로소프트에 의해 처음으로 브라우저에 탑재되었다

자바스크립트의 등장으로 웹 페이지에는 HTML 코드를 삽입해서 추가적인 요소를 보여주거나, 마우스 클릭이나 폼 입력 등의 이벤트들로 사용자와 상호작용하는 등의 여러가지 행동을 할 수 있게 됐다

단순히 사용자에게 정보만을 보여주던 정적 웹 페이지가 아니라, 사용자와 상호작용하고 사용자가 원하는 정보를 다양한 방식으로 보여줄 수 있게 된 것이다

4. CSS의 등장

스타일도 원래는 HTML 태그에 인라인으로 CSS를 작성했었다고 한다

그러다가 태그가 너무 길어지고 HTML 파일이 복잡해지면서 CSS가 등장했고, HTML 파일에 링크하는 방식으로 간단하게 가져와 쓸 수 있게 됐다

5. AJAX

Javascript 덕에 사용자와의 상호작용은 늘어나긴 했지만, 위의 PHP, ASP, JSP 시절까지만 해도 서버는 클라이언트 (브라우저) 쪽에 페이지 전체 (HTML, CSS, JS) 를 전송해 주어야 했다

데이터만을 보내서 클라이언트에서 추가적으로 렌더링하는 것이 불가능했기 때문에 서버에서 페이지 소스가 올 때마다 클라이언트는 매번 새 페이지를 처음부터 렌더링해 주어야만 했다

페이지를 처음부터 렌더링하다 보니 데이터를 불러올 때마다 흰색 빈 화면이 깜빡거리기도 하는 등 아무튼 불편한 시절이었다

 

AJAX는 페이지 전체가 아닌 데이터 일부만을 JSON 형태로 주고받는 새로운 정보 교환 기법으로, 서버는 최초 로딩을 제외하면 페이지 전체를 보내줄 필요가 없어 용량 절약이 되었고, 브라우저는 전달받은 JSON 데이터를 JS를 이용하여 적절한 형태로 화면에 그려주기만 하면 되기 때문에 모든 요소를 재렌더링할 필요 없이 필요한 요소만 렌더링하면 되어 간편했다

지금의 XMLHttpRequest 객체와 그를 래핑한 fetch, axios 등의 시초라고 볼 수 있다

6. JQuery

이때의 DOM 조작은 document.querySelector 등의 메서드들로 하나하나 찾아 변경해주어야 했고, 브라우저간 렌더링 방식이 다르기 때문에 모든 브라우저에 대해 따로따로 코드를 짜야 했다

이 페이지는 ~~ 브라우저에 최적화 되어 있습니다 라는 문구가 이 때의 잔재다

JQuery의 등장으로 이 귀찮은 코드 작업들이 굉장히 쉽고 간결해졌으며, 브라우저간 호환성도 JQuery가 어느 정도 커버해줬다고 한다

querySelector로 노드를 찾고, 노드의 속성을 일일히 변경하는 등의 작업을 매 줄마다 길게길게 따로 작성할 필요 없이, 메서드 체이닝으로 한두 줄만에 간단하게 코드를 축약해서 쓸 수 있었다

브라우저를 알아서 구별해준다는 점과 엄청난 간결함으로 JQuery는 굉장한 인기를 끌게 되었다

7. Angular → React → Vue

JQuery 시절만 해도 개발자가 어디에 무슨 요소가 있는지 다 꿰고 있어야 DOM을 조작하든 말든 했었다

또한 결국 데이터를 렌더링하기 위해선 서버로부터 데이터를 먼저 전달받고, 데이터의 내용에 따라 DOM을 직접 업데이트해줘야 했다

DOM을 하나하나 조작해줘야 한다는 점에서 앱의 규모가 커질 수록 유지보수하기도 점점 어려워지고, DOM을 조작할 일이 많아질 수록 연산량이 늘어나면서 성능이 매우 떨어진다는 단점이 있었다

이후 Angular, React, Vue 등의 프레임워크가 나오면서 자동으로 DOM을 업데이트해 주고, 컴포넌트 단위로 웹 요소들을 쪼개서 개발할 수 있게 되었으며 서버에서 데이터를 받아오는 로직과 엮어 여러가지 디자인 패턴을 적용시켜볼 수 있게 되었다

이와 더불어 document.querySelector 등 DOM을 직접 조작하는 방식이 레거시가 되면서 JQuery도 점점 황혼기에 접어들고 있다… JQuery를 사용하는 웹사이트가 아직 꽤 남아있긴 하지만, 신생 서비스들은 대부분 JQuery를 사용하지 않는다

---

참고자료

https://eroul-ri.tistory.com/5

https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d2314e190

https://fulcrum.rocks/blog/vue-vs-react-comparison

https://itworldyo.tistory.com/124

https://goddaehee.tistory.com/296

https://blog.logrocket.com/what-virtual-dom-react/

https://velog.io/@dosira686/React데이터-흐름

https://www.freecodecamp.org/news/what-is-lifting-state-up-in-react/

https://dj-min43.medium.com/리액트-virtual-dom-가상돔-버추얼돔-이란-359c28112048

https://dev-yakuza.posstree.com/ko/react/create-react-app/react/#선언형-프로그래밍

프론트엔드의 역사

https://velog.io/@minsangk/짧게-써보는-웹-프론트엔드의-역사

https://www.dong-ki.com/it/웹/231/

https://nihilog.github.io/post/2021-05-04-02-history-of-web

https://velog.io/@juno7803/React가-태어난-배경