2020 слишком сложный.Наконец-то я могу взять несколько выходных до Нового года, и я не имею никакого отношения к Weibo.Тогда я получил подарок из США:Vite2.0;
Вы в шоке! Новогодний подарок vite2.0, мне очень нравится, нельзя в праздники играть в игры и смотреть дорамы?
Увидев обновление, я не мог не зайти в официальную документацию, чтобы узнать. Я смотрел его несколько дней. Как раз когда я собирался читать документацию, пришли плохие новости с GitHub. За три дня 10 бета-версий Ты Юйси, ты просто дьявол;
Да ладно, каждый тоже может ощутить скорость дьявольского обновления... Это реально быстро и решительно, тысячу миль в день
В чем магия Vite с 10 изменениями за три дня?
Vite(французское слово, «быстро») — это новый тип инструмента для разработки интерфейсов; Первоначально он использовался с Vue 3.0, а затем был адаптирован для различных интерфейсных проектов.В настоящее время предоставляются шаблоны фреймворков Vue, React и Preact;
На данный момент Vue использует скаффолдинг vue-cli, а React обычно использует скаффолдинг create-react-app.
Зачем разрабатывать совершенно новый инструмент сборки, разве Webpack не плох? В чем разница между проектом, созданным с помощью Vite, и проектом, созданным с помощью Webpack? Появление нового инструмента должно быть связано с решением существующих проблем существующего инструмента, иначе новый инструмент не будет иметь ценности и значения;
Решает ли Vite эти проблемы с помощью Webpack?
Чтобы понять это, нам нужно сначала выяснить, что делает webpack? Первым впечатлением у многих людей должны быть «инструменты упаковки», так зачем вам нужны инструменты упаковки во внешнем интерфейсе? Что не так с фронтенд-разработкой до упаковки инструментов? Нужны ли нам инструменты для упаковки?
С развитием Интернета интерфейсные проекты становились все более и более сложными.В то же время движок V8 также позволил JavaScript, игрушечному языку, добавить крылья развитию коммерческих проектов, так что JS больше не нужен. Среда браузера больше не привязана к среде браузера и начинает выходить на системный уровень. Поле развития, поскольку сложность обновлений проекта требует одновременного улучшения спецификаций кода и управления. Поэтому в сообществе программистов было предложено множество модульных спецификаций. серверная сторона выбирает спецификацию CommonJS, а клиентская сторона выбирает спецификацию AMD.Тем не менее, есть также определенные проблемы с двумя спецификациями модульности.Обе являются программированием JS.Есть две разные спецификации модульности, которых недостаточно на уровне языка JS ;
Наконец, в ES6 комитет ECMA представил систему модулей на уровне языка:Спецификация модулей ES;
В современной практике программирования интерфейсное программирование выигрывает от разработки инструментов построения. Спецификация ES Modules широко используется в процессе кодирования, но серверная часть по-прежнему использует спецификацию CommonJS. Однако в NodeJS были внесены изменения, и постепенно к спецификации модулей ES;
Давайте возьмем небольшой код и кратко рассмотрим синтаксические особенности модулей ES.Модульность может помочь нам лучше решить проблему организации кода при разработке сложных приложений, но с введением идеи модульности у наших интерфейсных приложений появятся некоторые новые проблемы, такие как:
Прежде всего, модульная система ES Modules, которую мы используем, имеет неотъемлемые проблемы совместимости с окружающей средой. Хотя последние версии основных браузеров теперь поддерживают эту функцию, в настоящее время нет гарантии использования браузера пользователем. Поэтому нам также необходимо решить проблемы совместимости.
Во-вторых, слишком много файлов модулей разбито по модульному принципу, а фронтенд-приложение работает в браузере, и каждый файл нужно запрашивать с сервера отдельно. Разбросанные файлы модулей неизбежно приведут к тому, что браузер будет часто отправлять сетевые запросы, что повлияет на эффективность работы приложения.
Наконец, давайте поговорим о дивергенции, основанной на реализации модульности JS. С ростом сложности приложений не только код JavaScript должен быть модульным в процессе разработки внешнего интерфейса, но и файлы ресурсов, такие как HTML и CSS, также столкнутся с проблемой модульности. И с точки зрения макроса эти файлы также следует рассматривать как модуль во внешнем приложении, но тип и назначение этих модулей отличаются от JavaScript.
Для процесса разработки модульность определенно необходима, поэтому нам нужно внедрить лучшие решения или инструменты на основе вышеупомянутой модульной реализации для решения трех проблем, поднятых выше:Пусть наши приложения продолжают пользоваться преимуществами модульности на этапе разработки, не беспокоясь о влиянии модульности на производственную среду..
Я думаю, вы уже подумали, что именно по этой причине появляется ряд инструментов для создания пакетов, таких как webpack.Вышеупомянутые проблемы являются основными проблемами, которые должны быть решены этими инструментами;
По сути, webpack — это сборщик статических модулей для современных приложений JavaScript.
Инструмент создания шаблонов Vue vue-cli использует веб-пакет для упаковки.Во время разработки вы можете запустить локальный сервер разработки и просмотреть его в режиме реального времени.Поскольку весь файл проекта необходимо упаковать, сервер разработки запускается медленно
Та же проблема существует и для горячего обновления HMR после изменения файла во время разработки;
Горячее обновление Webpack будет пересобирать и упаковывать с текущим измененным файлом в качестве точки входа, и все задействованные зависимости также будут перезагружены один раз.
Vite очень хорошо решает две вышеупомянутые проблемы.
первый пришелпроблема с упаковкой, vite запускает сервер только для статической страницы и не упаковывает код файла.Сервер будет загружать различные модули в соответствии с запросом клиента для достижения реальной загрузки по требованию;
дляПроблема с горячим обновлением, vite немедленно компилирует измененный в данный момент файл, а также использует механизм кэширования ( http cache => встроенный кеш vite ) для загрузки обновленного содержимого файла.
Поэтому вит имеетБыстрый холодный старт, компиляция по требованию, горячее обновление модуляи другие отличные характеристики;
Таким образом, проект сборки vite и проект сборки vue-cli в основном находятся в режиме разработки, и разница довольно большая:
1: Vite может работать напрямую без упаковки в режиме разработки, используя модульные правила загрузки ES6; в режиме разработки Vue-CLI проект должен быть упакован для запуска;
2: Горячее обновление Vite на основе кеша, горячее обновление Vue-CLI на основе Webpack Сказав так много, как следует использовать вите?
Хотя официально он еще не выпущен, документация почти написана.vitejs.dev/guide/; Давайте просто будем использовать
Убедитесь, что версия узла больше или равна 12;
Используйте команду npm:
$ npm init @vitejs/app
Или используйте команду Пряжа:
$ yarn create @vitejs/app
После того, как команда будет выполнена, она позволит нам выбрать, какой проект фреймворка построить.Я напрямую выберу vue здесь.Если вы не хотите делать выбор в командной строке, вы можете указать конкретный шаблон
$ npm init @vitejs/app my-vue-app --template vue
Обратите внимание, что независимо от того, какой метод построения используется, загружается только шаблон кода проекта, а сторонние расширения, необходимые для запуска проекта, необходимо снова установить для запуска;
Перейдите в каталог проекта, установите необходимые зависимости и запустите проект:
cd <my-project>
npm install (or `yarn`)
npm run dev (or `yarn dev`)
Через файл package.json мы можем увидеть команды для запуска и упаковки
Запустите сервер разработки с помощью команды npm run dev:
Просмотрите текущие результаты:
Соберите проект с помощью команды npm run build:
Следует отметить, что код после успешного построения представляет собой статический файл ресурсов, и статический сервер по-прежнему должен быть предоставлен локально для запуска; Опыт здесь.Если вы хотите почувствовать скорость обновления дьявола, вы можете пойти на github, чтобы увидеть:github.com/vitejs/vite