vue3 + ts + pinia 그리고 vite

이전까지는 webpack기반으로 vue를 실행하는 vue-cli를 통해 개발해왔지만 1월 14일 Evan You의 세미나를 보고 새로운 과제가 생겼음을 깨닫게 되었다.

세미나 내용은 대층 vue3, pinia, vite가 vue의 표준으로 바뀌게 된다는 얘기들이었다.

 

vue3야 기존 vue2에서 지원되던 라이브러리 중 호환이 안되는 것 때문에 프로덕션 레벨에서 활용이 망설여졌지만 개인 프로젝트 정도는 충분히 할 가치가 있어 보인다(Composition API 등 ...)

ts는 이제 프론트엔드 개발자의 기본기나 다름없고..

사실 vuex가 불편한 지는 모르겠는데 pinia가 더 많은 개선을 들고왔다고 하니 사용해볼 예정. (pinia는 상태 관리 라이브러리이다.)

 

vite를 써야 하는 이유는 아래와 같다.

길었던 서버 구동

webpack은 번들링을 완료한 후 결과물을 확인할 수 있었지만 vite는 dependencies, source code 두 가지 카테고리를 나누어 개발 서버를 구동한다.

•  Depedencies: Plain JS 소스코드. vite의 pre-bundling 기능은 Go로 작성된 Esbuild를 사용하여 Webpack, Parcel 등의 기존 번들러 대비 10~100배 빠른 번들링 속도
•  Source code: vue컴포넌트와 같이 컴파일이 필요한 non-plain js 소스코드는 vite에서 Native ESM(es module)을 이용한다. 즉 브라우저가 곧 번들러이고 vite는 브라우저가 요청하는 특정 모듈의 소스코드만 전달할 뿐이다.

느렸던 소스 코드 갱신

기존 번들러는 소스 코드가 수정되면 다시 번들링 과정을 거쳤다. 모든 파일을 번들링 하는 비효율을 개선하고자 HRM(Hot Module Replacement)가 등장했으나 웹앱 사이즈가 커질수록 선형적으로 시간이 늘어났다.

vite는 ESM을 활용하여 웹앱 사이즈에 영향을 받지 않으며 더불어 HTTP 헤더를 활용하여 소스코드는 304 Not Modified로, 디펜던시는 Cache-Control 을 통해 캐싱을 구현하였고 최소한의 요청을 한다.

 

이러나 저러나 최신 기술인 만큼 여러 백업이 부족한 듯 싶다.

ESM을 활용하지만 지원이 안되는 브라우저도 존재하고 HTTP 요청에 따라 오버헤드가 발생할 수 있다.

또한 code-splitting 및 css 컴파일에 대한 처리가 미비하기 때문에 성장이 필요한 상황.

 

그전에 최신 기술의 맛을 좀 봐놔야 겠다.