реальность
До того, как браузеры стали поддерживать модули ES, JavaScript не предоставлял разработчикам встроенного механизма модульной разработки. Вот почему мы знакомы с концепцией «связки»: с использованием инструментов для захвата, обработки и объединения наших модулей исходного кода в файлы, которые можно запускать в браузере.
Со временем мы стали свидетелями такихwebpack,Rollupа такжеParcelПодобные изменения в инструментах значительно улучшили опыт разработки интерфейсных разработчиков.
Однако по мере того, как мы начинали создавать все более и более крупные приложения, объем кода JavaScript, который необходимо было обрабатывать, рос экспоненциально. Довольно распространены большие проекты с тысячами модулей. Мы начинаем сталкиваться с узкими местами в производительности — инструментам, разработанным с помощью JavaScript, часто требуется много времени (даже минуты!) для запуска сервера разработки, и даже с HMR требуется несколько секунд, чтобы результаты изменений файлов отобразились в браузере. . В этом цикле вялая обратная связь сильно повлияет на эффективность разработки и удовлетворенность разработчиков.
Vite стремится решить вышеуказанные проблемы с помощью новых разработок в экосистеме: браузеры начинают изначально поддерживать модули ES, и все больше и больше инструментов JavaScript пишут на скомпилированных языках.
медленный запуск сервера
При холодном запуске сервера разработки запуск на основе упаковщика должен сначала получить и собрать все ваше приложение, прежде чем его обслуживать.
Vite начинается с разделения модулей в приложении наполагатьсяа такжеисходный кодДве категории, улучшенное время запуска сервера разработки.
- полагатьсяВ основном чистый JavaScript, который не меняется во время разработки. С некоторыми более крупными зависимостями (такими как библиотека компонентов с сотнями модулей) также дорого обходиться. Зависимости также обычно существуют в нескольких модульных форматах (таких как ESM или CommonJS). Вите будет использоватьesbuildготовые зависимости. Esbuild написан на Go и выполняет предварительную сборку зависимостей в 10-100 раз быстрее, чем упаковщики, написанные на JavaScript.
- исходный кодОбычно содержит некоторые файлы, которые не являются непосредственно JavaScript, нуждаются в преобразовании (например, компоненты JSX, CSS или Vue/Svelte) и часто редактируются. В то же время не весь исходный код нужно загружать одновременно (например, модули кода, разделенные на основе маршрутизации). Вите сРодной ЕСМспособ предоставления исходного кода. Это эффективно позволяет браузеру взять на себя часть работы упаковщика: Vite нужно преобразовать исходный код только тогда, когда браузер запрашивает его, и обслуживать его по запросу. Код импортируется динамически в соответствии с контекстом, т. е. он будет обрабатываться только тогда, когда он действительно используется на текущем экране.
медленное обновление
Пересборка всего пакета неэффективна при запуске на основе упаковщика. Причина очевидна: потому что тогда скорость обновления будет падать по мере роста размера приложения.
Некоторые серверы разработки сборщиков хранят сборки в памяти, поэтому им нужно только деактивировать часть графа модулей при изменении файлов.[1], но по-прежнему требуется полная перестройка и перезагрузка страницы. Это дорого, и перезагрузка страницы удаляет текущее состояние приложения, поэтому сборщик поддерживает динамическую горячую перезагрузку модуля (HMR): позволяет модулю «горячую замену» себя, не затрагивая остальную часть страницы. Это значительно улучшает опыт разработки — однако на практике мы обнаружили, что даже в режиме HMR скорость горячего обновления значительно падает по мере роста размера приложения.
В Vite HMR выполняется на собственном ESM. При редактировании файла Vite нужно только точно деактивировать цепочку между редактируемым модулем и его ближайшей границей HMR.[1](Большинство самих модулей), так что независимо от размера приложения HMR всегда поддерживает быстрое обновление.
Vite также использует заголовки HTTP для ускорения перезагрузки целых страниц (опять же позволяя браузеру делать больше за нас): запросы на исходные модули будут согласовывать кеширование на основе 304 Not Modified, а запросы на зависимые модули будут проходить Cache-Control: max -age=31536000, immutable выполняет сильное кэширование, поэтому после кэширования их не нужно будет запрашивать снова.
Как только вы почувствуете скорость Vite, возникнет большой вопрос, готовы ли вы мириться с разработкой с помощью упаковщика, как вы привыкли.
Почему производственные среды по-прежнему необходимо упаковывать?
Хотя встроенные ESM теперь широко поддерживаются, по-прежнему неэффективно выпускать неупакованные ESM в рабочей среде (даже с HTTP/2) из-за дополнительных сетевых циклов, вызванных вложенным импортом. Для наилучшей производительности загрузки в производственной среде лучше всего выполнять древовидную загрузку, отложенную загрузку и разбиение кода на фрагменты (для лучшего кэширования).
Обеспечить согласованность оптимального вывода и поведения между сервером разработки и рабочими сборками непросто. Итак, Vite поставляется с наборомОптимизация сборкиизСоздать команду, из коробки.
Почему бы не упаковать с помощью ESBuild?
Хотя esbuild на удивление быстр и уже является отличным инструментом для создания библиотек, некоторые сборкизаявлениеВажные функции 's все еще находятся в стадии разработки, особенно разделение кода и обработка CSS. На данный момент Rollup является более зрелым и гибким в упаковке приложений. Тем не менее, мы не исключаем возможности использования esbuild в качестве производственной сборки, когда эти функции будут стабилизированы в будущем.