creact-react-app 벗어나기 (feat. Vite)

narc2ss·2022년 11월 14일
1

프론트엔드

목록 보기
1/2

들어가기전

create-React-App(이하 CRA)는 React를 처음 배우는 사람들 또는 프로젝트를 경험한 사람이라면 무조건 들어보고 사용했을 것이다.

CRA를 자주, 즐겨 사용하던 습관을 버리고자, 리서치한 결과를 정리해보고 WebpackVite를 비교해보고자 한다.

JavaScript 번들러로 본 조선시대 붕당의 이해 - 재그지그의 개발 블로그

Vite를 사용해야 하는 이유

문제점

브라우저에서 ESM을 지원하기 전까지는 JS 모듈화를 네이티브 레벨에서 진행할 수 없었고, 번들링이라는 우회적인 방법을 사용할 수 밖에 없었다.

  • Webpack
  • Rollup
  • Parcel

→ 생산성 향상

웹의 발전과, 대규모 애플리케이션이 처리해야 하는 JS 모듈의 개수가 증가함에 따라

  • 성능 병목 현상 발생
  • 개발 서버 가동시 시간 소요
  • HMR 적용시 시간 소요

→ 느린 피드백 루프로 인하여 생산성 저하

HMR(Hot Module Replacement): 새로고침 없이 번들링된 결과물이 반영되게 하는 설정

→ Vite는 브라우저에서 지원하는 ESM 및 네이티브 언어로 작성된 도구를 활용하여 문제해결

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

Bundle based dev server

*Cold-Start 방식으로 개발 서버 구동시 번들러 기반의 개발 도구는 애플리케이션 내 모든 소스 코드에 대해 크롤링 및 빌드 작업을 마쳐야 실제 페이지를 제공할 수 있다.

Cold-Start: 최초로 실행되어 이전에 캐싱한 데이터가 없는 상태

Native ESM based dev server

Vite은 이 문제를 Dependencies 그리고 Source code 두 가지 카테고리로 나누어 개발 서버를 시작하도록 함으로써 해결.

Dependencies

개발시 그 내용이 바뀌지 않을 일반적인(Plain) JS 소스 코드

  • 만약 Bundle based라면 수 많은 JS모듈을 갖고있는 컴포넌트 라이브러리에 대해 번들링을 실행할 것.
  • Vite의 pre-bundling 기능은 esbuild를 사용하고 있음.

Source code

JSX, CSS 또는 Vue/Svelte 컴포넌트와 같이 컴파일링이 필요하고 수정이 잦은(Non-Plain) JS 소스 코드

  • 필요할 때 요청하는 Dynamic import
  • Native ESM을 이용하여 소스 코드를 제공 → 브라우저가 번들러
  • 조건부 Dynamic import 이후의 코드는 현재 화면에서 실제로 사용되어야만 처리가 됨

느렸던 소스 코드 갱신

bundle based dev server에서는 소스 코드를 업데이트 하게 되면 번들링 과정을 다시 거쳐야 한다.

이러한 문제로 HMR이 나왔으나, 앱의 규모가 증가함에 따라 HMR 또한 선형적으로 시간이 증가한다.

Vite(Native ESM based dev server)는, ESM을 이용하여 HMR을 지원한다.

또한 HTTP Header를 이용해 캐시 되도록 하고 한 번의 요청이라도 덜 하도록 퍼포먼스를 높였다.

  • Dependencies: Cache-Control: max-age=31536000, immutable
  • Source code: 304 Not Modified

배포 시 번들링 과정이 필요한 이유

이제는 기본 ESM이 대부분의 환경에서 지원되지만 프로덕션에서 번들되지 않은 ESM를 가져오는 것은 중첩된 import로 인한 추가 통신으로 비효율적임.

프로덕션에서 최적화하기 위해서는 트리 셰이킹, 지연 로딩, 청크 파일 분할을 이용하여 번들링 하는 것이 더 좋음.

→ 최적화된 빌드를 위해 미리 준비된 빌드 커맨드빌드 최적화를 진행함.

빌드시 esbuild를 사용하지 않는 이유

번들링에 필수적으로 요구되는 기능이 아직 미비함.

  • code-spliting
  • css

결론

CRA는 편리하지만, 무겁고 설정을 변경하기 힘들다.
그렇기 때문에, React 프로젝트 구성시 번들러를 직접 적용하여

  • 개발 생산성 향상
  • 빌드속도 개선
  • 자유로운 커스터마이징

등 위와 같은 장점을 얻을 수 있다.

마치며

2년이라는 시간동안 웹 프론트엔드 실무를 하면서 CRA만 사용해왔었다.

돌이켜 생각해보면, SI 특성상 빠르게 만들고 보내야?하는 환경때문에 관심을 가질수가 없었던게 아닌가 싶다.

지금이라도 관심을 가져서 다행이라 생각하고, 늦은만큼 더 노력해야겠다고 다짐하게 되었다.

또한 누군가 번들러를 직접 구성해서 사용한다면 어느 아티클에서 봤던 비유(찾으면 링크 걸겠습니다🙇)를 건네주고 싶다.

여행갈 때 필요한 짐만 싸서 떠나야지

다음에는 간단한 프로젝트를 WebpackVite로 구성해보고 개발경험과 빌드 성능을 측정한 결과를 공유 해보겠음.

profile
시장은 빠르게 변화한다, 변화에 유려한 코드 짜기

0개의 댓글