[FE] webpack vs vite

번들러

JS 모듈을 단일 파일로 변환해 주는 도구

현재 vite, webpack, rollup 같은 상용와 된 번들러를 프로덕션 레벨에서 사용 중

번들러가 필요한 이유

브라우저에서 웹 애플리케이션을 구축하기 위해 요청을 보내면, 서버에서는 이를 구성하기 위한 여러 모듈 파일 전송

브라우저의 경우 먼저 요청된 파일부터 순차적으로 인게 받아 애플리케이션을 구성하기 때문에 만약 당장 구축에 필요한 파일이 나중에 인계된다면 딜레이가 더욱 커질 수 밖에..

또 모듈이 나뉠 때 마다 서버로 요청하는 파일의 개수가 증가하니까 더 느려질 수 밖에...!

 

Q. 하나의 파일에 모든 코드를 넣으면?

A. 공통된 컨텍스트 내에서 여러명이서 개발을...?

번들러가 어떻게 해결하는데?

기본적으로 번들러는 JS 모듈들을 하나로 묶는 기능을 함

=> 브라우저에서 각 파일 별로 요청을 보내지 않고 한 번의 요청으로 모든 파일을 받을 수 있음

=> 자연스럽게 HTTP 요청이 줄어들고 이로 인한 오버헤드 해결

 

각 모듈 간의 의존성 관계를 파악하여 올바른 순서로 모듈을 불러오고 실행될 수 있도록 보장

모듈 간의 의존성 문제와 전역 스코프 문제를 개발자가 직접 해결하지 않아도 된다...!

 

그 번들러 중에서 많이 사용되는 esbuild, rollup, vite, webpack에 대해서 알아보자

번들러가 이렇게 중요한데 난 왜 처음들어봤지...?

만약 React나 Vue.js 같은 라이브러리, 프레임워크를 사용한다면 이미 번들러가 내장되어있다

그래서 지금까지는 번들러를 몰라도 코드가 돌아갔던 것

 

하지만 바닐라 자바스크립트를 쓰게된다거나 혹은 성능상의 이유 등으로 기존의 번들러를 교체하고 싶다면 번들러를 반드시 알아야 하니까

성능하고 직결되기 때문에 중요하다

webpack

최근 1년간에 번들러 다운로드 수를 비교한 결과

사실 블로그를 보면서 공부할 때는 2년전 결과라서 webpack이 압도적으로 높았었는데 최근 esbuild에게 역전당했다

 

왜 webpack은 지금까지 많이 사용되었으며 왜 지금은 다운로드 수에서 밀릴까?

webpack은 Entry 포인트를 시작으로, 의존적인 모듈을 전부 찾아서 하나의 파일로 번들링 해줌

이 과정에서 webpack은

• 다양한 plugin과 loaders
  오래 되었고 사용자 수가 많기 때문에 커뮤니티가 크고 쉽게 plugin과 loader를 추가할 수 있음
• 강력한 개발 서버
  webpack이 사용하는 Hot Module Replacement가 소스코드의 변화를 감지하여 브라우저를 직접 새로고침 할 필요 없이 변화를 바로 반영
  그 외에도 작업 중인 상태나 데이터를 유지해주거나, 모듈 간의 일관성을 유지해 주기도 함
• Code Splitting 가능
  코드 스플리팅을 통해 번들 로드 최적화 가능
  파일들을 여러 번들 파일로 분리하여 병렬로 스크립트를 로드하여 페이지 로딩속도 개선 가능
  추가로 초기에 구동될 필요가 없는 코드를 분리하여 lazy loading을 통해 페이지 초기 로딩속도 개선도 가능

라는 장점들을 가지고 있다

=> 그럼 다른 번들링 툴을 사용할 필요가 없는게 아닌가

ESBuild

webpack에는 속도라는 치명적인 단점이 존재

webpack은 JS로 구성된 툴이고 해당 언어는 느림

거기다 프로젝트가 커질 수록 처리해야 할 코드의 양이 늘어나니까 성능 병목 현상 발생

=> 개발 서버를 가동하는데 오랜 시간을 기다려야 함

 

low-level language를 활용해서 툴을 만들면...?

 

성능상의 한계를 극복하기 위해 Go를 이용해서 만든 번들러가 ESBuild

=> 당연히 JS 기반의 번들러보다 10 ~ 100배까지도 빠름

 

다만 단점이 굉장히 명확하다

• code splitting 및 CSS와 관련된 처리가 미비함
• ES5 이하의 문법을 완벽히 지원하지 못함
• webpack 만큼 유연하지 못하고 안전성 관련한 이슈가 존재

Vite

위의 툴들의 단점을 커버하기 위해 나온 번들링 툴

ESBuild로 파일을 통합하고 Rollup을 통해 번들링

 

ES Module을 기반으로 동작하며, 개발 중에는 서버 사이드에서 모듈을 직접 제공

=> 브라우저가 ES Module을 직접 해석할 수 있도록 하며 번들링 과정을 생략

 

따라서 개발 환경에서의 빌드 속도가 매우 빠르고 변경사항이 있으면 즉시 반영

또한, Webpack과 비교해서 설정이 간단하고 사용하기 쉬움

webpack vs vite

기존의 번들러는 소스코드를 업데이트 하면 번들링 과정을 다시 거침

=> 규모가 클 수록 소스 코드 갱신 시간이 증가

 

Q. 그래서 HMR을 사용하는게 아닌가요?

A. 물론 vite 또한 HMR을 지원

그런데 번들러가 아니라 ESM을 이용해서

 

ESM을 이용하기 때문에 특정 모듈이 수정되는 경우 수정된 모듈과 그와 관련된 부분만 교체

=> 소스코드의 양이 많아져도 큰 영향을 미치지 않겠네?

ES Module

ES6 부터 도입된 모듈 시스템

export 및 import 문을 사용하여 분리되어있는 JS 파일 간의 접근을 가능하게 함

 

import 문을 사용하면 의존성 간의 연결이 생기고 Node가 어떤 코드를 불러와야 하는지 인식하는데 사용되며 import 문에서 지정한 파일이 의존성 그래프의 진입점이 되고 연결되어 있는 import 문을 따라가면서 의존성 그래프가 그려짐

 

=> 이러면 모듈 간의 의존성을 알 수 있고 특정 모듈이 수정되면 연관된 부분만 고칠 수 있지

대부분 ESM으로 해결하면 번들링의 필요성이 있나요?

프로덕션에서 최적의 로딩 성능을 얻으려면 트리 셰이킹, lazy loading 및 청크 파일 분할등을 하면 좋다

그러려면 아직까지는 번들링이 필요하고

그럼  왜 ESBuild가 아니라 다른 번들링 툴을 이용하죠?

ESBuild가 더 빠르긴 하지만 아직 불안정 함

비교적 유연한 플러그인인 Rollup이 성능 면에서 더 나을 것 같다는 개발자의 판단

Vite가 최선의 선택인가

Vite는 물론 매우 빠르고 간단한 설정을 제공하지만 비교적 사용자를 확보하지 못했고 작은 커뮤니티를 가지고 있음

그리고 SSR 지원 단계가 아직 experimental 단계

 

결국 개발 속도를 중요시 한다면 Vite를 선택하는게 맞겠지만

다양한 로더와 플러그인이 필요하다면 여전히 webpack도 매력있는 선택지

 

또한 이미 webpack을 사용중이라면 webpack의 플러그인이 모두 vite에서 동작할거란 보장도 없고 빌드 안정성도 떨어진다

=> 이런 경우에는 그냥 webpack을 그대로 사용하는게 더 나을 수도