그럼에도 불구하고

👨‍💻

[Bundler] 그래서 Webpack 있는데 Vite 왜 쓴다고? ( 번들러부터 익히기 ) 본문

이모저모/Bundler

[Bundler] 그래서 Webpack 있는데 Vite 왜 쓴다고? ( 번들러부터 익히기 )

zenghyun 2023. 10. 21. 00:08

 

요즘 추세를 보면 Webpack기반의 CRA보다 Vite를 많이 쓴다고 해요 

 

2021 JavaScript Rising Stars

 

"남들도 Vite 쓰니까~ 나도 Webpack 말고 Vite 써보자" 하고 썼던 나를 반성하는 글입니다.

( 최소한 이유는 알고 쓰자..ㅎㅎ )

 

ㅜㅜ

 

🧑🏻‍💻 번들러 ( Bundler) 

번들러는 여러개의 파일들을 하나의 파일로 묶어주는 도구입니다.

 

번들러는 웹 개발에서 사용되는 도구 중 하나로, 웹 애플리케이션을 개발하거나 배포할 때 사용됩니다. 번들러의 주요 역할은 여러 개의 웹 리소스 파일, 예를 들면 JavaScript 파일이나 CSS 파일 그리고 이미지 파일 등을 하나의 번들(묶음)로 결합하고 최적화하는 것입니다. 

이러한 작업을 통해 웹 애플리케이션의 성능을 향상하고 로딩 시간을 줄일 수 있습니다.

 

번들링을 하지 않는다면 매우 많은 네트워크 요청이 필요하게 됩니다. 

 

그중에서 가장 각광받고 있는 번들러는 Webpack입니다.

 

📌 Webpack 

웹팩(Webpack)은 JS 애플리케이션을 위한 가장 인기 있는 번들러 중 하나입니다.

 

👉 설정이 간편하고 직관적임

하나의 설정 파일에서 원하는 번들이 생성되도록 컨트롤할 수 있습니다.

entryoutput을 명시하고 어떤 pluginloader로 파일을 다룰 건지 명시하면 됩니다.

 

👉 다양한 plugins과 loaders

webpack은 강력한 개발 커뮤니티로 인해 쉽게 plugin과 loader를 추가할 수 있습니다. loader를 통해 파일들을 변환, 번들링, 빌드를 진행하고 plugin을 통해 output 파일을 튜닝해 줄 수 있습니다.

 

👉 강력한 개발 서버

webpack은 Hot Module Replacement(HMR)를 사용하는데 HMR은 소스코드의 변화를 감지하여 브라우저를 직접 새로고침할 필요가 없이 변화를 바로 반영해 줍니다. 그 외에도 작업 중인 상태나 데이터를 유지해 주거나, 모듈 간의 일관성을 유지해주기도 합니다.

( 그저 빛.. )

 

👉 Code Splitting 

코드 스플리팅을 통해 번들 로드를 최적화할 수 있습니다. 파일들을 여러 번들 파일로 분리하여 병렬로 스크립트를 로드하여 페이지 로딩속도를 개선할 수 있습니다. 추가로 초기에 구동될 필요가 없는 코드를 분리하여 lazy loading을 통해 페이지 초기 로딩속도를 개선할 수 있습니다.

 

📎 우리가 CRA를 써왔던 이유

Create React App( CRA ) 써서 리액트 프로젝트를 생성한 경험, 다들 있으시죠?

CRA는 facebook React Team에서 추천하는 공식 React boilerplate이며, HMR과 같은 유용한 기능을 제공합니다. 기본적으로 번들링이 필요한데 Webpack의 여러 가지 장점을 다 사용할 수 있으니 CRA는 많이 쓰였습니다. 

 

하지만, 장점만 있는 건 아닙니다.

 

CRA는 Webpack을 사용합니다. Webpack은 자바스크립트 코드로 구성된 툴인데 JS는 interpreted 언어이기 때문에 느립니다. 또한,  프로젝트가 커질수록 처리해야 할 코드의 양이 많아지기 때문에 성능 병목 현상이 발생되었고, 개발 서버를 가동하는데 비합리적으로 오랜 시간을 기다려야 하는 단점이 생겼습니다.

 

느린 피드백이 반복되면 개발자의 생산성과 만족도는 매우 낮아지기 때문이죠.

그래서 개발자들은 Go와 같은 low-level language를 활용하여 자바스크립트 툴을 만들게 되는데 

 

그렇게 만들어진 게 ESBuild입니다.

 

엄청나게 빠른 esbuild

 

📌 ESBuild

ESBuild 기존의 번들러가 내부적으로 JavaScript 기반으로 번들링 하기 때문에 성능상의 한계를 극복하고자 만들어졌습니다.

 

ESBuild는 내부적으로 GO로 작성되었고 JS 기반의 번들러보다 10배에서 100배까지 빠른 엄청난 퍼포먼스를 보여줬습니다.

( 번들러로서의 필수적인 기능도 갖춤 )

 

⭐️ 장점

  • 네이티브 코드 방식을 사용
  • 병렬 처리의 최적화
  • 메모리 사용 최적화
  • 자체적인 JavaScript Parser 채택 

⭐️ 단점

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

 

Vite는 ESBuild를 단점을 보완하여 만들어진 프론트엔드 빌드툴입니다.

 

📌 Vite

공식 홈페이지에 따르면, Vite는 "빠른"이라는 의미의 프랑스어로 오늘날 웹 프로젝트에 더 빠르고 가벼운 개발 경험을 제공하는 것을 목적으로 하는 빌드 도구입니다.

 

Vite는 크게 두 가지 키 포인트로 나눌 수 있습니다.

 

1.  Native ES modules  기반의 강력한 개발 서버 

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

 

전반적으로 ESBuild로 성능을 끌어오고 Rollup을 통해서 번들링의 유연성을 챙깁니다. 

 

📎 그래서 왜 Vite가 빠른 건데?

Webpack 기반의 프로젝트와 비교했을 때 Vite 기반의 프로젝트가 dev server를 시작하는데 훨씬 더 빠릅니다.

 

dev server 시작 시간이 빠른 이유는 예상할 수 있듯이 ESBuild를 이용하여 종속성을 미리 묶어버리기 때문입니다. 

 

Vite는 번들을 두 가지 부분으로 분류합니다.

 

  1. 외부 의존성: 외부 의존성은 개발하는 동안 바뀌지 않는 일반적인 자바스크립트를 말합니다. ( node_modules와 같은 import 되는 JS module ) Webpack은 브라우저의 요청 이전에 모든 자바스크립트 모듈을 처리하는 반면, Vite은 ESBuild를 이용하여 외부 의존성만 미리 번들링 해놓습니다. 여기서 ESBuild는 자바스크립트 기반의 번들러보다 10~100배 빠르게 의존성을 미리 번들링 합니다.
  2. 내부 프로젝트 코드 (ES Module): Vite는 네이티브 ESM을 통해 소스 코드를 제공합니다. (.jsx, .vue. .scss 등) 이는 번들러 작업의 일부를 브라우저에 인계하는 것으로, 브라우저 요청 시마다 소스 코드를 변환하고 제공하기만 하면 됩니다. 조건부 동적 가져오기 뒤에 있는 코드들은 현재 화면에서 실제로 사용되는 경우에만 처리됩니다.

이는 서버가 시작되기 전에 코드를 번들링 하여 시간을 소비하지 않는다는 것을 의미합니다.

 

기존의 Bundler

 

Vite

 

📎 Vite가 번들링을 미리 하는 이유 

대부분의 브라우저가 기본적으로 ES Module Loading을 지원하지만, 모든 유저가 최신 브라우저를 사용하는 게 아니라면 여전히 번들링은 필요합니다. 번들링을 하지 않는다면, 여러 모듈을 가져오기 위해서 매우 많은 네트워크 요청이 필요하게 됩니다.

 

최적화된 Loading Performance를 얻기 위해서는 트리 쉐이킹(tree-shaking), 지연 로딩(lazy loading), 그리고 더 나은 캐싱을 위한 청크 스플리팅(chunk splitting)을 이용하여 코드를 번들링 하는 것이 좋습니다.

 

📎 Vite는 HMR도 남달라 😉

HMR은 다른 페이지에 영향을 끼치지 않고, 특정 모듈만 즉시 반영이 될 수 있게 해 줍니다. 

 

그러나 프로젝트의 크기가 커질수록, HMR의 시간 또한 길어지게 되어 생산성 저하로 이어집니다.

Vite는 번들러가 아니라 네이티브 ESM을 기반으로 HMR을 구현하기 때문에 다른 번들링 툴보다 우위에 있습니다. 모듈이 수정됐을 때, Vite는 수정된 모듈과 관련된 부분만 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐입니다. 모든 과정에서 완벽하게 ESM을 이용하기 때문에, 앱 사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않습니다. 

 

📎  Vite SSR ( Server Side Rendering )

Vite는 SSR에서도 사용할 수 있지만, 아직 experimetal 단계라고 합니다. 

 

자세한 내용은 아래 링크를 참조해 주세요 :) 

 

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

 

Vite

Vite, 차세대 프런트엔드 개발 툴

ko.vitejs.dev

📎  그럼 CRA 쓰고 Vite 쓰는 좋을까

위에서 언급한 것처럼 CRA 대신에 Vite를 많이 사용하는 추세라고 합니다. 번들링 속도 향상이 주는 메리트가 크기 때문이겠죠? 

Vite가 지금보다 더 안정되거나 앞으로 SSR을 폭넓게 지원한다면, 더 많이 사용될 수 있지 않을까 조심스레 예상해 봅니다. :) 

 

기존 CRA 기반의 프로젝트를 Vite로 변경하는 데는 Webpack에서 디테일한 설정들을 사용하고 있을 수 있기 때문에, 고려해야 할 상황이 많지만 Webpack에서 기본적인 설정만 사용한다면 더 나은 개발 경험을 위해 Vite를 쓰는 게 좋지 않을까 생각도 듭니다. 

 

🧑🏻‍💻 결론

  • Vite는 외부 번들링을 미리 해놓아서 개발 서버의 시작 속도를 높인다.
  • Vite는 핫 모듈 리플레이스먼트를 위해 네이티브 ES모듈을 활용한다. 따라서 더 빠르게 코드의 변경 사항이 반영될 수 있다.
  • Vite 합리적인 기본 설정값을 가지고 있어서 최소한의 설정으로도 개발을 진행할 있다.

👉 출처

https://velog.io/@sehyunny/is-it-time-to-say-goodbye-to-webpack

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

https://bepyan.github.io/blog/2023/bundlers

https://velog.io/@eamon3481/Vite-%EB%8A%94-Webpack%EC%9D%84-%EB%8C%80%EC%B2%B4-%EA%B0%80%EB%8A%A5%ED%95%A0%EA%B9%8C

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

 

 

Comments