Vite 사용하는 이유

Dependencies

→ 사전 번들링은 esbuild로 해서 빠름

1. CommonJS 그리고 UMD 모듈을 ESM으로 가져오기
2. 퍼포먼스
   1. 여러 디펜던시가 존재하는 ESM 모듈을 하나로 변환

Source Code

→ 수정이 잦은 파일은 다이나믹 import

• ES modules 사용 이전은 JavaScript 모듈화를 네이티브 레벨에서 진행
  • 번들링을 우회적으로 사용
    • 모듈화 된 소스 코드를 브라우저에서 실행할 수 있는 파일은 묶어 연결
  • Webpack, Parcel을 통해 번들링 작업
    • 프론트엔드 개발자 생상성 증대
• 어플리케이션 발전함에 따라서 처리하는 JavaScript 모듈 개수가 극적으로 증가
  • JavaScript 기반 도구의 성능 병목 현상 발생
    • 서버 가동에 오랜 시간 소요
    • HMR을 사용해도 변경 파일에 수초 이상 소요
• 브라우저에서 지원하는 ES Modules(ESM) 및 네이티브 언어로 작성된 JavaScript 를 활용하여 문제 해결

History

ESBuild

• Go Lang 으로 만들어져서 엄청 빠르지만 빌드만 함.
• 기능 통합이 안됨

HMR (rollup, snowpack)

• esbuild로 빌드하고, 브라우저 표준 방식으로 개발을 만들어 내는 방식

• 각각 모듈을 별도로 빌드하고, 수정 발생시 해당 파일만 다시 빌드해서 업데이트

  ⇒ 빌드시에는 esbuild 활용

• 파일 수정시 새로고침 없이, 수정된 파일 내용만 반영(Rollup, Snowpack)

• Snowpack은 loader 호환 문제

Vite

• 에반유가 좋은 컨셉을 본인화하여 간결하고 나은 버전
• Esbuild, 모듈을 이용한 개발모드, 개발 서버, 프록시 서버, 번들 툴, 코드 스프리팅, HMR
  • 번들 도구 기능을 모두 모아 만듬
  • 컨셉을 모두 흡수
  • 안정성, 훌륭한 문서 제공
  • 2021 가장 높은 만족도를 얻은 툴
• HMR을 지원한다.
  • ESM을 통해서 지원한다.
  • 수정된 모듈과 관련해서 교체한다.
  • 브라우저에서 해당 모듈을 요청하면 교체 모듈만 전달한다.
    • 사이즈가 커져도 갱신 시간에는 영향이 없다.
  • vite는 HTTP 헤더를 이용해 퍼포먼스 캐싱
    • 필요에 따라 소스 코드는 304 Not Modified
    • 디펜던시는 Cache-Control: max-age=31536000,immutable