Рассказать о статус-кво и идеях построения фронтенд-проекта

внешний интерфейс JavaScript
  • суг команда
  • Автор: Луис

источник

После нескольких лет осадок реформа начального этапа наконец вышла на плато на этом этапе. Оглядываясь назад на путь, по которому шли предшественники, в основном нужно решить следующие проблемы:

  • Языковые функции, поддерживаемые браузерами, не очень дружелюбны, что влияет на эффективность разработки.
  • В проекте отсутствует управление зависимостями, копирование-вставка слишком неэффективна и трудно поддается контролю
  • Необходимы инструменты для сжатия кода, сжатия изображений, генерации хэшей файлов для управления кешированием браузера и т. д.
  • Сохранение кода во время разработки может обновить браузер в режиме реального времени, чтобы улучшить процесс разработки.

Для решения этих проблем появились следующие решения:

  • babel, преобразуйте ES6 и typescript в код ES5, поддерживаемый браузерами
  • DSL (доменный язык), например: меньше, sass и т. д. для расширения css, jsx, шаблон vue, угловой шаблон для расширения html
  • Инструмент управления зависимостью NPM
  • Используйте инструменты для обработки сжатого кода, сжатия изображений, создания HASH файлов и других функций.
  • Используйте инструменты live reload, browsersync, hot reload для обновления браузера в режиме реального времени.

Эти решения стали незаменимыми функциями в нашей разработке, поэтому нам нужен инструмент, чтобы соединить их вместе, поэтому перед и после появляются интерфейсные инженерные инструменты построения, такие как grunt, gulp, fis, webpack и т. д. После периода обновлений и итераций, с идеей о том, что все является модулем и его мощными функциями, веб-пакет постепенно выделяется из многих инструментов и становится широко используемым инструментом построения во внешних проектах.

статус-кво

На данном этапе я лично чувствую, что построение фронтенд-проектов становится все тяжелее и громоздче. Для нового проекта всегда необходимо установить кучу зависимостей (сотни M node_modules), а затем написать кучу элементов конфигурации для инструментов сборки, прежде чем можно будет выполнять бизнес-разработку. Когда проект становится все больше и больше, каждый его запуск занимает много времени. Потому что инструмент сборки должен выполнить анализ зависимостей и компиляцию проекта и, наконец, вывести файлы, которые может выполнить браузер. На данный момент оптимизация конфигурации инструментов сборки поставлена ​​в рабочий график каждого.

Текущая схема оптимизации построения, на примере webpack, в основном имеет следующие направления:

  • Облегчить анализ зависимостей: решить конфигурацию веб-пакета, исключить конфигурацию лодера.
  • Подпакет, динамическая загрузка: import(), require.ensure()
  • Извлеките общие части и уменьшите количество зависимостей, которые необходимо скомпилировать: DllPlugin, внешние компоненты.
  • Параллельная компиляция с многопоточностью и многопроцессорностью: thread-loader, happyPack
  • Кэш: кеш-загрузчик, жесткий-исходный-веб-пакет-плагин

Тем не менее, бизнес-код достигает определенного уровня (выше 5 Вт строк), после указанной выше оптимизации скорость действительно значительно увеличивается, но лично я чувствую, что это все еще немного тяжело для разработчика (среды разработки).

идея

видел когда-то@vue/dev-serverПосле этого инструмента меня внезапно осенило, и я придумал реальное решение. Этот инструмент может быстро запустить.vueОднофайловая среда разработки, давайте посмотрим, что она делает.

Файлы, созданные в соответствии с документацией, не имеют конфигурации, такой как webpack.config, и не имеют предварительно обработанных выходных файлов.

Файл index.html использует модуль es, поддерживаемый последним браузером Chrome, для загрузки main.js.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Vue dev</title>
</head>
<body>
  <div id="app"></div>
  <script type="module">
    import './main.js'
  </script>
</body>
</html>

Файл main.js представляет собой файл test.vue, который совпадает с файлом ввода обычного проекта. Код в файле test.vue — это формат обычного одиночного файла vue, который не отображается.

import Vue from 'vue'
import App from './test.vue'

new Vue({
  render: h => h(App)
}).$mount('#app')

Далее посмотрим на загружаемые браузером ресурсы, путь тот же, что и при импорте, а тип — скрипт (Content-Type: application/javascript).

основной.js,import Vue from 'vue'обработано вimport Vue from '/__modules/vue'. Поскольку модуль браузера es еще не реализован, он все еще предлагаетсяimport-mapsфункция, поэтому зависимости без путей не поддерживаются. Vue — это vue.js, который может выполнять браузер.

test.vue — это код после компиляции исходного файла, потому что исходный.vueОднофайловые браузеры не поддерживаются и должны быть предварительно скомпилированы.

Видно, что инструмент фокусируется на использовании промежуточного программного обеспечения для выполнения следующих действий:

  • Преобразуйте ссылочный адрес зависимостей без путей (пока это только vue, другие пакеты npm не обрабатываются), чтобы браузеры могли поддерживать
  • предварительно скомпилировано.vueфайл, преобразованный в поддерживаемый браузером js, аналогичный vue-loader в webpack

Тщательно обдумав это, текущие инструменты сборки обрабатывают все файлы ресурсов, от которых зависит проект, но во многих случаях мы разрабатываем только определенный модуль на определенной странице. С идеальной точки зрения, по сути, нам нужно обрабатывать только файлы ресурсов, от которых зависит страница. Всякий раз, когда загружается ресурс, который не может быть выполнен браузером: vue, sass, less и т. д., выполняется процесс перевода/компиляции, и, наконец, файл ресурса выводится в браузер.

Фактически, некоторые люди в сообществе предпринимают аналогичные попытки, например:systemjs, описание на гитхабе:Dynamic ES module loader. Конечно, это делается не только для совместимости с модулем es на стороне браузера, основное внимание уделяется его реализации.Transform loaderФункция. Эта функция предоставляет функцию, аналогичную загрузчику webpack, и выполняет соответствующую обработку загрузчика для сопоставления зависимостей. Конкретная обработка загрузчика может быть размещена в веб-воркере или обработана через сервер узла.Если он совместим с большинством загрузчиков веб-пакетов, это хорошее решение.

В настоящее время идея еще не проверена и не реализована.Если вам интересно, вы можете узнать о соответствующем содержании.Если будут дальнейшие исследования, я надеюсь на общение и обсуждение вместе.

Категории