Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Wonjun Hwang
Mais de Wonjun Hwang (20)
Último
Último (6)
Vite
- 7. Vite의 서버구동 2. Source code
- 8. Vite의 소스갱신
- 9. Vite의 빌드최적화
- 11. Vite 시작하기
Notas do Editor
- 제가 오늘의 팀스 주제로 정한 내용은 vite이라고 하는 자바스크립트 빌드툴입니다. Vite는 vue의 창시자 이기도 한 evan you 에반유 가 만들었는데 vue뿐만 아니라 react, svelt, vanilla js 모두 지원합니다. vite 자체 단어의 뜻은 프랑스어로 fast(빠르다)는 라는 뜻입니다. Vite은 기본적으로 모던 웹 프로젝트를 위한 빠르고 간결한 개발 경험을 제공하는데 초점을 맞추고 있습니다.
- Vite은 기본적으로 빌드툴인데 개발시 데브서버와 빌드시 rollup으로 번들하는 작업을 함께 제공합니다. 데브 서버를 제공하는데 네이티브 es module를 넘어 다양한 기능을 함께 제공합니다. 예를 들어 엄청나게 빠른 HMR 기능을 제공힙니다. 두번째 효율적인 번들링입니다. Vue cli를 사용해본적이 있으면 vue cli와 조금 비슷하지만 더 간결하고 빠른 서비스를 제공합니다.
- Vite 웹사이트에 소개부분에 vite를 이렇게 소개합니다. 즉각적인 서버 구동, 빠른 HMR – 앱 사이즈랑 상관없이 빠른 HMR를 제공한다고 합니다., 풍부한 기능 - typescrip, js, css 추가적인 모듈 설치 없이 사용 가능합니다., 빌드 최적화 - 웹앱 및 라이브러리의 빌드 최적화를 위한 기본적인 설정을 제공, 범용적인 플러그인들 - 개발 서버 및 빌드 과정 모두 사용 가능한 롤업 플러그인 인터페이스 제공,.
- Vite이 해결하려고 하는 문제는 feedback loop speed 입니다. 그러니까 개발시 발생하는 feedback loop speed 입니다. 왜냐하면 이러한 느린 피드백 루프는 개발자의 생산성에 영향을 줄 수 있기때문입니다. Vue cli를 사용해본적이 있으시면 큰 프로젝트에서는 dev server를 시작할때 어플리케이션 내 모든 소스 코드에 대해 크롤링 및 빌드 작업을 마쳐야 실제 페이지를 제공할 수 있었습니다. 그리고 프로젝트가 커질수록 HMR이 점점 느려지고 변경된 파일이 적용될 때에도 수 초 이상 소요되곤 햇습니다. 그냥 한 파일을 수정할때에도 스크린에 업뎅이트 될때까지는 수 초이상을 기다려야했습니다. 이러한 문제점이 근본적으로 발생하는 이유는 번들링의 필요때문입니다. 그럼 왜 번들링이 필요할까요?
- 애초에 자바스크립트에서는 module이 없었습니다. 왜냐면 자바스크립트가 탄생했을 당시에는 웹에서 자바스크립트로 대형 어플리케이션을 만들겠다는 상상도 하지 못했기 때문입니다. 자바스크립트는 본래 간단한 동작만 하기 위해 만들어져서 파일을 여러개로 만들어서 개발 할 수도 없었습니다. 파일을 여러개로 분리할 수 없으면 거대한 프로젝트를 만들기에도 불리합니다. 예전에 네이티브 es modules가 없을때에는 브라우저가 이 모듈라이즈된 코드를 지원할 수 없었습니다. 그래서 AMD와 CommonJS 같은 모듈시스템이 개발되고 그 포멧에 맞게 코드를 작성한 후 webpack이나 parcel 같은 번들러를 이용해 하나의 싱글 파일로 변환하면 그제서야 브라우저에 돌릴 수 있었습니다. 그런데 다행이도 현대의 대부분의 브라우저는 기본적으로 es module 를 지원합니다. 그래서 vite는 이런한 es module과 네이비트 언어로 만들어진 자바스크립트 툴를 활요하여 서버를 빠르게 구동할 수 있었습니다. 이러한 초점에 맞춰 vite는 브라우저에서 지원하는 es module 및 네이비트 언어로 작성된 javascrip 도구등을 활요해 앞서 말씀드린 문제들을 해결하려고 했습니다. 이 의미는 우리가 개발하는 동안 많은 일을 해야하는데, 우리가 그러한 일까지 해아하는지, 왜냐면 브라우저가 기본적으로 해주기 때문입니다.
- 그럼 vite는 어떻게 dev serve를 빠르게 구동할 수 있을까요? 우선 vite는 서버를 구동할때 모듈을 두개의 카테고리로 나눕니다. Dependecies랑 source code로요. 디펜던시는 개발하는동안 잘 변하지 않는 일반적이 자바스크립트 소스코드들에 대한 것입니다. 기존 번들러로는 비효율적으로 시간이 많이 걸렸는데 이 부분을 vite는 사전번들링 이라는 과정으로 esbuild를 사용합니다. 그럼 왜 esbuild는 다른 번들러보다 빠른까?? Esbuild는 go 언어로 작성된 모듈 번들러인데 cto, figma, evan walace 라는 분이 만들었는데 native 언어로 컴팡일 되기 때문에 자바스크립트로 기반의 다른 번들러보다 보시는 바와 같이 많게는 100배 더 빠릅니다. 스크립트 기반의 느린 js 가 아니라 go의 경우 컴파일 단계에서 소스 코드를 전부 기계어로 변환해 실행하는 단게에서 소스 코드가 기계어로 변환되는 작업이 생략되고 또 멀티스레드 기반이기 때문에 휠씬 빠른 퍼포먼스를 보여줍니다. 그럼 왜 이렇게 빠른 esbuild를 사용하지 않는것일까요? 왜냐면 esbuild를 이용하여 개발이 가능한 것은 보통 바닐라 스크립트 형태의 라이브러리 등이기 때문에 프레임워크를 기반으로 하는 웹 개발은 기본 webpack과 같은 번들러를 사용해야 했습니다.
- 그래서 그러한 수정이 잦고 컴파일이 필요한 non plain javascript 같은 jsx, css, vue, react는 vite에서는 어떻게 처리가 될까요? Cousre code 카테고리에서는 jsx, css vue,react, 같은 컴파일링이 필요하고 수정 또한 잦은 non plain javascript 입니다. 기존 번들러는 서버가 구동되기 전에 모든 파일을 크롤링하고 번들이 되어야 구동이 됩니다. 그러나 vite에서는 기본적으로 브라우저에게 번들링 작업을 맞기고 vite는 라우트 기반 코드 스플릿를 사용하여 한번에 소스코드를 로딩할 필요가 없이 그냥 트랜스폼transform과 브라우저가 요청하는대로 소스코드를 보내주면 됩니다. Code behind conditional dynamic imports is only processed if actually used on the current screen.
- 기존 번들러 기반 개발을 진행할때 소스 코드를 업데이트 하게 되면 번들링 과정을 다시 거쳐야 했습니다. 서비스가 커질수록 소스 코드 갱신 시간 또한 증가합니다. 이러한 문제를 해결하기 위해 HMR이라는 대안이 나왔으나 그럼에도 불구하고 앱 사이즈가 커질수록 갱신에 필요한 시간은 증가하게 되었습니다. Vite도 물론 HRM를 지원합니다. 번들러가 아닌 es module를 사용합니다. 어떤 모듈이 수정되면 vite는 수정된 모듈과 관련된 부분만을 교체할 뿐이고 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달하기만 합니다. 전 과정에서 es module를 사용하기 때문에 앱 사이즈가 커져도 갱신 시간에는 영향을 끼치지 않습니다.
- 빌드시 rollup은 때때로 공통(common) 청크 파일을 생성합니다. 최적화 되지 않은 경우 먼저 비동기적으로 A청크를 불러와지고 A청크가 모두 파싱된 후에 C청크가 필요하다는 사실을 알게 되어 네트워크 왕복이 필요합니다. Vite는 preload스탭을 이용해 a를 가지고 올때 c 청크를 병렬적으로 가지고 올수 있도록 하여 쓸데 없이 낭비되는 네트워크 왕복을 줄이도록 구성합니다.
- 이러한 vite의 기능들때문에 2021년 가장 만족도가 높고 관심도도 높은 번들툴이 됩니다.
- Vite에서 새로운 프로젝트를 만드려면 npm create vite@latest를 작성하면 끝납니다. 처음에는 프로젝트 이름 적는 부분이 나오고 프레임워크 선택하고 javascript 아니면 타입스크립트 선택할지 정하고 설치가 완료되면 npm install 하여 서버를 실행하면 됩니다. 보시는 바와 같이 모듈도 https://github.com/vitejs/awesome-vite#templates