vite을 사용하면 좋은 이유

date
Sep 3, 2022
thumbnail
slug
vite을 사용하면 좋은 이유
author
status
Published
tags
React
summary
왜 Vite을 사용해야 하나요?Vite을 사용해야 하는 이유를 정리한 글입니다. 서론비트? 빗? 그게 뭔가요? 먼저 vite은 빠른 웹 프로젝트 개발 경험에 포커스를 맞춰 탄생하게 된 빌드 도구에요.발음은 veet과 비슷한 vit입니다.
type
Post
updatedAt
Jan 22, 2023 01:19 AM

왜 Vite을 사용해야 하나요?

Vite을 사용해야 하는 이유를 정리한 글입니다.

서론

비트? 빗? 그게 뭔가요?
먼저 vite은 빠른 웹 프로젝트 개발 경험에 포커스를 맞춰 탄생하게 된 빌드 도구에요.발음은 veet과 비슷한 vit입니다.

이런 문제점이 있었어요.

브라우저에서 ESM을 지원하기 전까지 개발자들은 번들링이라는 방법을 사용해야했었어요.번들러로 잘 알려진 Webpack, Rollup, Parcel과 같은 도구는 이런 번들링을 진행함으로서 프론트엔드 개발자의 생산성을 크게 향상 시켰죠.
앱이 더욱 발점함에 따라 JavaScript 기반의 도구는 성능 병목 현상이 발생하게 되었고 개발 서버(local)를 가동하는데 오랜시간을 기다려야 했습니다.
Vite은 이런 것에 초점을 맞춰 브라우저에서 지원하는 ES Modules와 네이티브 언어로 작성된 JavaScript 도구를 활용해 문제를 해결하고 있어요.

너무 길었던 서버 구동

콜드-스타트 방식(캐싱한 데이터가 없는 경우)으로 개발 서버를 구동할 때, 번들러 기반의 도구의 경우 앱 내의 모든 소스코드에 대해 빌드 작업을 마쳐야 페이지를 제공할 수 있습니다.
Vite은 위 문제를 dependencies, source code 두가지 카테고리로 나눠 개발서버를 시작하도록 함으로서 해결했어요.
  • Dependencies: 개발 시 그 내용이 바뀌지 않을 일반적인 JavaScript 소스 코드입니다. 기존 번들러로는 컴포넌트 라이브러리와 같이 수백개의 JavaScript 번들링 과정이 매우 비효율적이었고 많은 시간을 필요로 했습니다.Vite의 사전 번들링 기능은 Esbuild를 사용하고 있습니다. Esbuild는 Go로 작성되었기 때문에 기존 Webpack과 Parcel 대비 10-100배 빠른 시간을 보여주고 있죠.
  • Source code: Vite은 Natice ESM을 이용해 소스 코드를 제공하고 있는데요. 즉, 브라우저가 번들러라는 말입니다. Vite은 그저 브라우저의 판단 아래 특정 모듈에 대한 소스코드를 요청하면 이를 전달할 뿐입니다. 따라서 조건부 동적 import 이후의 코드는 현재 화면에서 실제로 사용이 되어야만 처리가 됩니다. JSX, CSS, Component와 같이 컴파일링이 필요하고 수정이 잦은 소스 코드들이 해당되겠죠?

기존 번들링을 사용하는 Dev Server

notion image

ESM을 적용한 Dev Server

notion image

느렸던 소스 코드 갱신

기본 번들러로 개발할 때 소스 코드를 업데이트하면 번들링 과정을 다시 거쳐야 했어요.
일부 번들러의 겨웅 메모리 상에서 이를 진행하고 갱신에 영향을 받는 파일들만 새롭게 번들링을 하도록 하였으나 결국 이것도 처음에는 모든 파일에 대한 번들링을 진행해야하죠.
"모든 파일"을 번들링하고 이를 다시 웹 페이지에서 불러오는 것이죠.
이런 이슈를 해결하기 위해 HMR(Hot Module Replacement)이라는 것이 대안으로 나왔지만 명확한 해답을 아니었습니다.
HMR: 앱을 종료하지 않고 갱신된 파일만을 교체하는 방식 -> 다만 앱 사이즈가 커질수록 갱신에 필요한 시간이 증가한다.
Vite도 번들러가 아닌 ESM을 이용해서 HMR을 지원합니다.어떤 모듈이 수정되면 vite은 수정된 모듈과 관련 부분을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달합니다.모든 과정에서 ESM을 이용하기 때문에 앱 사이즈가 커져도 갱신기간에는 영향을 끼치지 않습니다.
vite는 HTTP 헤더를 이용해 퍼포먼스를 한 단계 높였습니다. 필요에 따라 소스 코드는 304 Not Modified로, 디펜던시는 Cache-Control: max-age=31536000,immutable을 이용해 캐시되도록 함으로서 한 번의 요청이라도 덜 하도록 개발되었어요.

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

다양한 이점을 가진 ESM이지만, 비교적 최근에 지원되기 시작했기 대문에 사용이 불가능한 브라우저 환경이 있을 수도 있습니다.또한 네트워크를 통해 필요한 시점에 해당 모듈을 요청하기에, HTTP/2를 이용하더라도 오버헤드가 발생될 수 있구요.따라서 배포시에는 번들링 과정이 필수적이에요.

왜 번들링 시에는 Esbuild를 사용하지 않을까요?

Esbuild는 매우 빠른 속도로 번들링이 가능하지만 코드 분할과 CSS 관련된 처리가 미비합니다.따라서 Vite은 보다 검증된 툴인 Rollup을 사용하고 있습니다.
어떤 사람이 사용하면 좋을까요?