Create React App vs Vite

  이번 시간에는 리액트 프로젝트를 생성할 때 Vite를 사용하는 이유에 대해서 알아보겠습니다.

Create React APP

  대부분의 개발자들은 보통 Create React App(CRA)을 이용하여 리액트 프로젝트를 생성했습니다. CRA는 리액트 팀이 추천하는 공식 리액트 보일러 플레이트(react-boilerplate)이기도 하고, HMR(Hot Module Replacement)과 같은 유용한 기능을 제공하기 때문입니다. 컴퓨터 프로그래밍에서, 보일러 플레이트 코드 또는 간단히 보일러 플레이트(boilplate code)는 변형이 거의 없는 여러 장소에서 반복되는 코드의 섹션입니다.

 

  CRA는 Webpack을 사용합니다. Webpack은 자바스크립트 코드로 구성된 툴로 웹팩의 핵심은 현대 자바스크립트 애플리케이션을 위한 정적 모듈 번들러입니다. 웹팩이 애플리케이션을 처리할 때, 내부적으로 하나 이상의 진입점으로부터 의존성 그래프를 구축하고, 그 후 프로젝트가 필요로 하는 모든 모듈을 하나 또는 그 이상의 번들로 결합합니다. 이러한 번들은 콘텐츠를 제공하기 위한 정적 자산입니다. 그리고 웹팩은 노드 모듈중에 하나이기 때문에 기본적으로 Node.js 가 설치되어있어야 합니다. 다시말해, 웹팩은 웹에서 사용되는 모든 자원(assets)을 번들링 해주는 도구입니다. 번들링의 개념은 여러개의 파일 중에 종속성이 존재하는 파일을 하나의 파일로 묶어 패키징을 시키는 과정을 의미합니다. 번들링을 하는 이유는 다음과 같습니다. 그리고 웹팩을 사용하면 자바스크립트 간의 종속성 뿐만 아니라 자바스크립트 내에서 필요한 css나 img와 같은 파일(.css, .jpg)도 번들링해서 하나의 파일로 합쳐줘서 네트워크 요청을 최소화 시킬 수 있습니다.

• 파일을 하나로 합쳐 네트워킹 요청횟수는 줄어들게됩니다. 
• 중복된 소스코드도 최소화하고 모듈 개념을 사용하기 때문에 글로벌이 오염되지 않습니다.

출처: https://webpack.js.org/

  자바스크립트는 interpreted 언어이기 때문에 느립니다. 처리해야 할 코드 양이 방대한 경우, 그 단점이 확인할 수 있습니다. 애플리케이션이 점점 더 발전함에 따라 처리해야 하는 JavaScript 모듈의 개수도 극적으로 증가하고 있습니다. 심지어 수천 개의 모듈이 존재하는 것도 대규모 프로젝트에서는 그리 드문 일이 아닙니다. 이러한 상황에서 JavaScript 기반의 도구는 성능 병목 현상이 발생되었고, 종종 개발 서버를 가동하는 데 비합리적으로 오랜 시간을 기다려야 한다거나 HMR을 사용하더라도 변경된 파일이 적용될 때 까지 수 초 이상 소요되곤 했습니다.

  이와 같은 느린 피드백 루프는 개발자의 생산성과 행복에 적지 않은 영향을 줄 수 있습니다. 그래서 개발자들은 Go와 같은 저급언어(low-level language)를 활용하여 자바스크립트 툴을 창조하였는데, 그렇게 해서 생겨난 게 Esbuild입니다. Esbuild는 Go 언어로 작성된 자바스크립트 빌드툴입니다. 번개 같은 속도를 자랑합니다.

Esbuild is almost 120 times faster than Webpack

Vite

  Vite는 Esbuild를 기반으로 만들어진 프론트엔드 빌드툴입니다. Vite는 위에서 언급한 성능 병목현상에 초점을 맞춰, 브라우저에서 지원하는 ES Modules(ESM) 및 네이티브 언어로 작성된 JavaScript 도구 등을 활용해 문제를 해결하고자 합니다. ES 모듈 활용 덕에 자바스크립트 코드를 모두 번들할 필요 없이 브라우저에서 자바스크립트 어플리케이션을 작동시킬 수 있습니다. Vite의 핵심은 간단합니다. 

• ES 모듈을 사용하여 브라우저가 필요로 하는 어플리케이션 코드의 일부분만 변환하고 제공하는 겁니다.

지루할 정도로 길었던 서버 구동

vite는 애플리케이션의 모듈을 dependencies와 source code 두 가지 카테고리로 나누어 개발 서버의 시작 시간을 개선합니다.

• Dependencies: 개발 시 그 내용이 바뀌지 않을 일반적인(Plain) JavaScript 소스 코드입니다. 기존 번들러로는 컴포넌트 라이브러리와 같이 몇 백 개의 JavaScript 모듈을 갖고 있는 매우 큰 디펜던시에 대한 번들링 과정이 매우 비효율적이었고 많은 시간을 필요로 했습니다.
  • Vite의 사전 번들링 기능은 Esbuild를 사용하고 있습니다. Go로 작성된 Esbuild는 Webpack, Parcel과 같은 기존의 번들러 대비 10-100배 빠른 속도를 제공합니다.
• Source code: JSX, CSS 또는 Vue/Svelte 컴포넌트와 같이 컴파일링이 필요하고, 수정 또한 매우 잦은 Non-plain JavaScript 소스 코드는 어떻게 할까요? (물론 이들 역시 특정 시점에서 모두 불러올 필요는 없습니다.)

vite는 Native ESM을 이용해 소스 코드를 제공합니다. 이것은 본질적으로 브라우저가 번들러의 작업의 일부를 차지할 수 있도록 합니다. vite는 브라우저가 요청하는 대로 소스 코드를 변환하고 제공하기만 하면 됩니다.

느렸던 소스 코드 갱신

출처: https://ko.vitejs.dev/guide/why.html

  기존의 번들러 기반으로 개발을 진행할 때, 소스 코드를 업데이트 하게 되면 번들링 과정을 다시 거쳐야 했었습니다. 따라서 서비스가 커질수록 소스 코드 갱신 시간 또한 선형적으로 증가하게 됩니다. "모든 파일"을 번들링 하고, 이를 다시 웹 페이지에서 불러오는 것은 매우 비효율적입니다. 이러한 이슈를 우회하고자 HMR(Hot Module Replacement) 이라는 대안이 나왔으나, 이 역시 명확한 해답은 아니었습니다.  HMR은 나머지 페이지에 영향을 끼치지 않고, 특정 모듈만 "즉시 반영" 될 수 있도록 해 줍니다. 그러나 프로젝트의 크기가 커질 수록, HMR의 시간 또한 길어지게 되므로 이는 생산성 저하로 이어지게 되는 것입니다.

출처: https://ko.vitejs.dev/guide/why.html

  물론, vite는 HMR을 지원합니다. 이는 번들러가 아닌 ESM을 이용하는 것입니다. 어떤 모듈이 수정되면 vite는 그저 수정된 모듈과 관련된 부분만을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐입니다. 전 과정에서 완벽하게 ESM을 이용하기에, 앱 사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않습니다. 또한 vite는 HTTP 헤더를 활용하여 전체 페이지의 로드 속도를 높입니다.

  따라서 Vite는 네이티브 ESM을 기반으로 HMR을 구현하므로 다른 번들링 툴보다 우위에 있다고 할 수 있습니다. 모듈이 수정되면, Vite는 수정된 모듈과 관련된 부분만을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐입니다. 이는 어플리케이션의 크기와 관계 없이 HMR을 언제든 빠르게 이뤄지도록 합니다.

핵심 요약

• Vite는 번들링을 생략하여 개발 서버를 빠르게 구동시킬 수 있다.
• Vite는 더 빠른 리로딩과 캐싱을 위해 HTTP 상태 코드를 활용한다
• Vite는 HMR을 위해 native ESM을 사용한다. 따라서 앱에 대한 변경사항이 빠르게 반영된다.
• Vite가 설정한 최소한의 config로도 사용할 수 있다.

참조

https://ko.vitejs.dev/guide/why.html

Vite

https://steemit.com/javascript/@noreco/webpack

웹팩(webpack) 이란? — Steemit

https://velog.io/@jaewoneee/%EB%A6%AC%EC%95%A1%ED%8A%B8-%EB%B3%B4%EC%9D%BC%EB%9F%AC%ED%94%8C%EB%A0%88%EC%9D%B4%ED%8A%B8-Create-React-App-vs-Vite

왜 Create React App 대신 Vite일까