React의 등장부터 특징까지
react 이전에도 많은 라이브러리/프레임워크 존재했다.
이들 대부분은 MVC, MVVM, MVW 패턴을 기반으로 만들어졌다.
Models가 공통점인데 Models란 관찰 가능한 객체로 뷰와 양방향으로 바인드되어, 뷰가 변경되면 모델도 업데이트된다.
이 모델 패턴은 mutation을 권장하는데 이는 상당히 복잡하다. 또한 DOM 변화가 발생하면 렌더링이 일어날 수밖에 없고, 이는 비용이 많이 든다.
Model에 있는 값이 변하면 View에서도 이를 같이 변화(mutation) 시켜주고, 반대로 View에서 어떤 값을 변화(mutation) 시키려고 하면 Model에 있는 값을 변화시켜준다.
결국 연산을 줄이기 위해 뷰에 초점을 둔 react 라이브러리가 나오게되었다.
"변화(mutation)을 하지 말자. 그 대신에 데이터가 바뀌면 View를 날려버리고 새로 만들어버리면 어떨까?"
언제든 view를 선언할 수 있고, jsx문법을 사용해 간편하고 쉽게 사용할 수 있다.
또한, 관찰 가능한 객체 바인딩이 존재하지 않는다. 이러한 관찰 가능한 객체가 있다면 mutation이 계속해서 발생하기때문에 react는 이를 구현하지 않았다.
또한 jQuery는 js보다 적은 양의 코드로 개발할 수 있기 때문에 오랬동안 사랑받았다.
하지만 사용자 interaction이 많아지면서 성능이 중요해졌다. jQuery를 이용하면, 배치와 화면 표시에 많은 연산을 발생시켜서 브라우저 성능이 낮아진다.
jQuery는 HTML의 클라이언트 사이드 조작을 단순화 하도록 설계된 크로스 플랫폼의 자바스크립트 라이브러리다. 2006년 웹 디자이너 존 레식에 의해 공식적으로 소개되었다.
Single Page Application
전통적인 웹 페이지는 모든 페이지마다 HTML, CSS, JavaScript 파일을 각기 가지고 있어야 했다. 기본 틀(마크업)은 HTML로 만들고, CSS로 옷(스타일)을 입히며 JavaScript로 웹에 활기(동적으로 제어)를 불어넣어 준다. 페이지 간 이동할 때마다 HTML,CSS, JavaScript 파일을 서버와 주고받았기 때문에 속도가 느릴 수밖에 없었다.
SPA는 HTML,CSS, JavaScript 파일을 최초 1회만 로드하고, 이후에는 JavsScript를 통해 DOM 또는 필요한 HTML 파일을 조작한다.
SPA 렌더링 과정
- https://velog.io/@yes3427 에 접속한다.
- 이 주소는 Domain 주소에 해당하므로 DNS 서버로 가서 IP 주소를 받아서 서버에 요청을 보낸다.
- 서버가 클라이언트에게 index.html과 App.js를 보낸다. (SPA이므로 index.html 단 하나만 존재)
- 서버로 부터 받은 파일들로 Render Tree를 구성하고, 실제 화면에 렌더링한다.
SPA는 첫 로딩에 하나의 페이지만 가져오기 때문에 첫 화면을 보기까지 오래 걸릴 수 있다. 따라서 SEO에 불리하다.
SEO는 Search Engine Optimization으로 구글이나 네이버와 같은 검색엔진에서 검색을 했을 때 노출되는 것을 뜻한다.
주로 검색엔진은 <meta> 태그에서 해당 웹사이트 정보를 크롤링 해오는데, SPA 방식은 index.html이 하나이기 때문에 해당 정보는 유일하여 원하는 페이지에 대한 SEO가 적절하지 않을 수 있다. 이를 해결하기 위해서 next.js 가 대체재를 이루고 있다.
이 후 구글에 의해 Angular.js 프레임워크가 등장했다. 하지만 user interaction이 증가하고, 복잡성이 증가할수록 데이터 흐름을 파악하기가 너무 어려웠다.
그래서 React가 등장했다. 페이스북도 유사한 문제를 가지고 있었고, 데이터가 어디서 어디로 흐르는지 명확히 알 수 있는 장점을 가졌다.
React 핵심 개념
1. Virtual DOM
DOM을 조작하는 전통적인 방식은 Imperative 했다.
Imperative는 DOM에 보여지길 원하는 모든 요소들을 하나 하나 정확하게 명령하는 것이다.
모든 단계를 하나하나 지정해주는 것이 명확하지만, 다양한 유저 이벤트와 edge case에서 각각의 변화가 어떤 연관성을 가지는지 파악하기 어렵다.
복잡한 SPA에서는 DOM 조작이 많이 발생한다.
DOM 조작을 하면 render tree를 재생성하고, 레이아웃을 만들고 페인팅 하는 과정이 다시 반복된다. 만약 50개의 노드를 하나 하나 수정하면, 50번의 레이아웃 재계산과 30번의 리렌더링을 초래한다.
브라우저에게 DOM을 해석하고 렌더링 하는 것은 굉장히 비싼 작업이다. 따라서 DOM 조작은 성능에 병목을 일으키는 요인 중 하나이다.
DOM 변경
- 모든 요소들을 다시 레이아웃을 계산하여 화면에 위치시키는 작업(reflow)
- 변경되어야 하는 요소를 페이지에 다시 칠하는 과정(repaint)
이 부분에서 VirtualDOM이 빛을 발한다.
VirtualDOM은 컴포넌트 단위로 움직이는 Declarative한 개발을 구현하기 위해 도입되었다.
react의 render 함수가 return 하는 것은 새로운 VirtualDOM을 만들기 위한 재료이다.
새롭게 만들어진 VirtualDOM을 만들고, React-DOM 라이브러리가 Diffing 알고리즘 을 통해 실제DOM과 비교하여 어떤 부분이 달라졌는지 찾아내어 바뀐 부분만 실제DOM에 적용한다. 따라서 연산의 양을 줄이면서 성능이 개선된다.
이렇게 모든 변화를 하나로 묶어서 적용하면 레이아웃 계산과 리렌더링의 규모는 커지겠지만 연산의 횟수는 훨씬 줄어든다.
React는 실제 DOM보다 빠르다는 건 잘못된 사실이다. 사실은: 유지보수 가능한 어플리케이션을 만드는 것을 도와주고 대부분의 경우 '충분히 빠르다'
-React의 창시자이자 React 개발 팀원 Dan Abramov-
2. Component
react는 재사용 가능한 컴포넌트를 만들고, 이 컴포넌트들이 모여 웹사이트를 구성한다. 이 컴포넌트는 자바스크립트 함수(또는 객체)이다. state를 세팅하고, 이를 기반으로 화면에 어떻게 보여지기를 원하는지 작성하여 하나의 컴포넌트를 구성한다.
이후 react에 내장된 Component 라이브러리 기능을 불러온 후, 여기에 내장된 render() 메소드를 통해 ReactDOM 라이브러리에 rendering될 컴포넌트를 전달하여 최종적으로 ReactDOM 라이브러리가 현재 DOM과 전달받은 컴포넌트를 비교하여 변경이 필요한 부분만 변화를 주어 화면에 보여주게 된다.
3. One Way(Unidirectional) Data Flow
데이터의 흐름이 one-way로 제한되기 때문에 디버깅이 편리해진다. SPA의 복잡성으로 인한 데이터 흐름 추적의 어려움을 상당 부분 해결할 수 있다.
단점은 변화를 감지하고 화면을 업데이트 하는 코드를 매번 작성해야 한다는 것이다.
4. react는 UI
Angular.js의 경우, 앱을 만드는데 필요한 모든 것이 갖춰진 프레임워크다. 반면 react는 라이브러리다. 화면이 어떻게 보여질지만 도움을 주고, 그 외 모든 것들은 알아서 처리해야한다.
이러한 특성 때문에, react 라이브러리를 그대로 ReactDOM 라이브러리 대신 ReactNative 라이브러리와 결합시키면 앱을 만들 수 있고, React360 라이브러리와 결합하면 VR을, ReactElectron과 결합시키면 데스크톱 앱을 만들 수 있다. 따라서 자바스크립트 기반으로 모바일, VR, 데스크톱 어떤 것이든 만들 수 있는 크로스 플랫폼 역할을 한다.
마무리
둘 다 사용해본 결과 확실히 React가 Vue보다 자유도가 높았다.
프레임워크는 부분적 사용이 불가능하지만, 라이브러리는 필요할때만 쓸 수 있다.
v-for로 작성하던 코드를 forEach, for, map 등 다양하게 작성할 수 잇다. 이렇게 하므로써 얻는게 무엇일까? 라는 생각을 해보았다. 자유도가 높은게 무조건 좋은것인가?
우선 자유도가 높으면 상황에 따라서 개발자가 자유롭게 대처할 수 있다는 점이 좋다.
하지만 개발자 마다의 코딩 스타일이 달라서 협업시 통일하는데에 커뮤니케이션 비용이 든다는 단점이 있다.
이전에는 마냥 자유도가 높으면 좋겠다라는 생각을 했지만 무조건 좋은 것 만도 아닌 것 같다.
https://medium.com/@RianCommunity/react의-탄생배경과-특징-4190d47a28f
