webpack과 vite

ESM(ES Modules)가 등장하기 전까진 Javascript 모듈화를 네이티브 레벨에서 진행할 수 가 없었습니다.

따라서 개발자들은 번들링(bundling)이라는 우회적인 방법을 사용할 수 밖에 없었습니다.

(번들링: 모듈화된 소스 코드를 브라우저에서 실행할 수 있는 파일로 한데 묶어 연결해주는 작업)

 

이 같은 상황에서 webpack, rollip 같은 도구로 번들링 작업을 하며 프론트엔드 개발자의 생산성을 향상 시켰습니다.

 

하지만, 1000개가 넘는 JavaScript 모듈이 있는 거대한 프로젝트라면 어떨까요?

실제로 이러한 상황을 어렵지 않게 마주할 수 있으며, 이 경우 Webpack과 같은 JavaScript 기반의 도구는 병목 현상이 발생하곤 합니다. (개발 서버를 실행하는 데 있어 비합리적으로 긴 시간을 기다려 본 적이 있나요? 또는 HMR을 사용할 때 편집한 코드가 브라우저에 반영되기까지 수 초 이상이 소요되어 답답했던 적이 있나요?)

 

vite는 이러한 것에 초점을 맞춰, 브라우저에서 지원하는 ES Modules(ESM) 및 네이티브 언어로 작성된 JavaScript 도구 등을 활용해 문제를 해결하고자 등장했습니다.

webpack

대표적인 번들러로 여러 가지 장점을 가지고 있습니다.

 

- 10년 넘게 개발, 관리되며 여러 참고 레퍼런스와 장점이 있습니다.

- Code Splitting이나 Tree Shaking 등을 잘 지원합니다.

- 모듈을 IIFE 방식으로 묶어주어 여러 브라우저 지원 가능

 

시간이 지나고 웹이 발전하면서

ES Module(ESM)을 브라우저에서 지원해 <script type="module">로 불러올 수 있게 되었고 (import&export)

> require.js와 같은 도움이 없이 자바스크립트 레벨에서의 언어화 모듈

1~2년 사이에 Native 바람이 불어오며 다양한 번들이 등장하게 되었습니다.

 

보통 번들링 시엔 다양한 작업이 동시에 이뤄지는

- TS => JS로 트랜스 파일링

- 플러그인과 폴리필 적용

 

대부분의 번들러는 NodeJs 기반으로 돌아가며, 번들링 중 진행되는 트랜 스파 일링 등 역시 대부분 NodeJs로 돌아갑니다.

문제는 NodeJs는 싱글 스레드 구조이기 때문에 이로 인한 한계가 발생합니다.

 

위의 동작을 Native 영역에서 돌려 성능을 끌어올리기 위한 시도들이 나타나기 시작했고

golang을 기반으로 하는 esbuild, Rust를 기반으로 하는 SWC가 대표적입니다. 특히 esbuild는 안정성이 높아 다른 번들러에서 Vite, Snowpack 등에서 래핑 하여 사용하고 있습니다.

 

esbuild

esbuild는 Rollup과 비슷한 느낌이며 기본적인 entry, output 등을 설정한 뒤, sass나 svgr 등 필요한 플러그인을 추가로 설치해 적용했습니다.

 

기존에 210초 정도 걸리던 빌드가 2초 정도에 끝날 정도로 속도면에서 엄청난 장점을 가지고 있었습니다.

 

그러나 HMR(Hot-Module Replacement)를 공식적으로 지원하지 않아 어려움이 있었고

 

이외에 Babel 트랜스 파일 지원 미흡 등의 단점이 있었습니다.

vite

기본적으로 ES Modules를 사용하며 Rollup처럼 쉽게 설정할 수 있습니다.

 

esbuild로 미리 트랜스 파일링 해놓은 뒤에 로컬에서 개발 서버를 띄우면, 소스 코드를 불러오면서 의존성이 있는 패키지만 가져오고, 한 번 빌드한 결과는 캐싱해두어 다음 개발 빌드 때 바로 뜹니다.

 

vite가 빠른 속도를 낼 수 있는 이유

- esbuild를 이용해 종속성을 미리 묶는다.

- esbuild는 golang 언어로 작성된 매우 빠른 번들러로 특화된 병렬 처리를 이용해 빠름

- ESM을 통해 소스코드를 제공

> 이것은 브라우저가 번들러 작업의 일부를 인계받게 하는 것입니다

> Vite는 브라우저가 요청할 때 요청에 따라 소스 코드를 변환하고 제공하기만 하면 됩니다.

 

Rollup

- 코드들을 동일한 수준으로 올리고 한 번에 번들링함

> 식별자 충돌을 방지하기 위해 식별자를 변경함

 

webpack

- 모든 모듈을 함수로 랩핑

 

 

 

요약

기존의 번들러 기반으로 개발 진행 

 

> 소스 코드 업데이트 시 번들링 과정을 다시 거쳐야했음(HMR이 있지만 마찬가지로 선형적으로 비용이 증가)

> 서비스가 커질 수록 소스 코드 갱신 시간이 선형적으로 증가

 

Vite는 ESM을 이용해 소스 코드를 제공함

> Vite의 사전 번들링 기능은 Esbuild를 사용하고 있습니다. Go로 작성된 Esbuild는 Webpack, Parcel과 같은 기존의 번들러 대비 10-100배 빠른 번들링 속도를 보임

> 모듈 수정 시 모듈과 관련된 부분만 교체(번들러가 아닌 ESM을 통한 HMR / hot module reload  )

> 브라우저가 곧 번들러가 된다.

> Vite는 브라우저의 판단 아래 특정 모듈에 대한 소스 코드를 요청하면 전달만 하면됨

 

현재 Vite는 Webpack을 완전히 대체할 수 있을까?

 

> 그러나 프로덕션 빌드에선 esbuild를 사용하지 않고 Rollup을 사용하고 있는데 그 이유는

> 용량이 큰 프로덕션 버전에서 필요한 트리 쉐이킹이나 코드 스플리팅과 같은 최적화 기능을 제공하지 않기 때문

 

Vite는 확실히 번들링 속도에서 큰 메리트가 있습니다.

그러나 아직 SSR 지원 폭이 좁으며 esbuild 또한 webpack에 비해 안정성이 떨어진다는 의견이 있습니다.

현재 많은 현업에서 Vite를 도입하는 추세이지만 위의 문제들이 해소된다면 webpack의 다운로드 수를 넘어설 수 있지 않을까 싶습니다!

 

 

출처

https://engineering.ab180.co/stories/webpack-to-vite

Webpack → Vite: 번들러 마이그레이션 이야기