Будущее без Webpack

внешний интерфейс Программа перевода самородков Webpack

Пусть в будущем не будет Webpack

Пакеты npm, установленные с помощью @pika/web, можно запускать прямо в браузере. Вам все еще нужен бандлер в этом случае?

Сейчас 1941 год. Тебя зовут Ричард Хаббелл. Вы работаете в экспериментальной нью-йоркской телестудии, принадлежащей CBS. Вы собираетесь вести крупный телевизионный выпуск новостей, одно из первых телешоу в мире, и у вас есть 15 минут до конца. Вы знаете, что вы собираетесь делать через мгновение?

В мире, где люди знают только радио, вы будете придерживаться своего познания. И ваше восприятие на данный момент таково, что вы собираетесь читать пресс-релиз.«Телевизионные новостные передачи Хаббелла в значительной степени написаны по сценарию, с редкими переходами к карте или неподвижному изображению».Пройдет некоторое время, прежде чем люди увидят настоящие видеоматериалы в телевизионных новостях.

Как разработчик JavaScript в 2019 году я чувствую то же самое. Очевидно, у нас уже есть эта новая система модулей JavaScript (ESM), он может работать непосредственно в веб-среде. Но каждый раз, когда мы что-то разрабатываем, нам все равно приходится использовать для этого инструмент упаковки. Почему это?

За последние несколько лет индустрия упаковки JavaScript превратилась из оптимизированной для производства в обязательную для разработки. Нравится вам это или нет, но трудно отрицать, что инструменты упаковки привносят извращенный уровень сложности в веб-разработку, область, которая всегда гордилась тем, что исходный код виден и прост в использовании.

@pika/web пытается спасти веб-разработчиков от упаковки ада. Это 2019 год, и вы должны использовать упаковщик, потому что хотите, а не потому, что должны.

Credit: @stylishandy

Почему мы упаковываем

Упаковка JavaScript — это не что иное, как молодое вино в старых бутылках. В старые времена (ха-ха, около 6 лет назад) сжатие и слияние файлов JavaScript в продакшене было нормой. Это может повысить скорость загрузки веб-сайта и обойтиУзкое место параллельных запросов HTTP/1.1.

Изначально эта оптимизация лучше или нет, но почему она стала абсолютно необходимым шагом в процессе разработки? Это самая безумная часть: большинство веб-разработчиков никогда специально не просят об упаковке. Наоборот, упаковка — это всего лишь побочный эффект, чего мы действительно жаждем, так это чего-то другого —npm.

npm— который в то время расшифровывался как «инструмент управления пакетами Node.js» — находится на пути к тому, чтобы стать крупнейшим реестром кода за всю историю. Фронтенд-разработчики хотят принять участие. Единственная проблема заключается в том, что его модульная система в стиле Node.js (Common.js или CJS) не работает в веб-среде без упаковки. Таким образом, Browserify,Webpackи другие современные инструменты веб-упаковки.

创建 React 应用的视觉化展现：一大堆依赖包

Получите интуитивно понятное представление о создании приложений React: Для запуска «Hello World» требуется установить более 1300 зависимостей.

сложный стокгольмский синдром

Сегодня, если вы хотите разработать веб-проект, вам не нужноWebpackТакие упаковочные инструменты в принципе невозможны. просто возьмиСоздать приложение React (CRA)Например, когда вы хотите быстро создать проект, но обнаруживаете, что вам нужно сначала установить более 1300 различных зависимостей, весь раздутыйnode_modulesПапка имеет размер 200,9 МБ, и вы просто хотите запустить «Hello World»!

Как и Ричард Хаббелл, мы все настолько увязли в трясине инструментов упаковки, что слишком легко игнорировать тот факт, что все может быть совсем по-другому. Теперь у нас есть так много хороших современных зависимостей ESM (Почти 50 000 на npm!). Что мешает нам использовать их непосредственно в веб-среде?

Ну, причин очень много. 😕 Чрезвычайно легко написать собственные веб-модули ESM самостоятельно, и действительно есть некоторые пакеты npm без зависимостей, которые могут работать непосредственно в веб-среде. Но, к сожалению, подавляющее большинство пакетов npm не работают. Сам пакет наследует зависимости, от которых он зависит, или особый способ, которым пакеты npm импортируют зависимые пакеты по имени пакета, вот причины.

Вот почему создайте@pika/web.

@pika/web: веб-приложения без упаковки.

использовать@pika/webУстановленные современные зависимости npm можно запускать прямо в браузере, даже если у этих зависимостей есть свои собственные зависимости. Сделайте это за один шаг. Это не инструмент сборки и не инструмент упаковки (в традиционном смысле). @pika/web — это инструмент времени установки пакета зависимостей, который значительно уменьшает ваше желание использовать другие инструменты и даже может полностью избавиться от него.WebpackилиParcelТакие камни преткновения.

npm install && npx @pika/web
✔ @pika/web installed web-native dependencies. [0.41s]

@pika/web проверимpackage.jsonфайл, проверить"dependencies"Все зависимости, которые экспортируют действительные точки входа модуля ESM и устанавливают их локальноweb_modulesпапка. @pika/web работает со всеми пакетами ESM, даже с некоторыми из ESM-смешанных внутренних зависимостей Common.js.

Установленные зависимости могут работать в браузере, поскольку @pika/web упаковывает каждый пакет в отдельный модуль ESM, который может поддерживать веб-среда..jsдокумент. Например: весь пакет "preact" соответствует файлуweb_modules/preact.js. Такой механизм может устранять возможные недостатки внутри пакета, сохраняя при этом исходный интерфейс пакета.

"Эй, ты ждешь минуту!" Вы могли бы сказать,«Разве это не другое место для упаковки? Поменяйте суп, но не лекарство!»

Вот так!@pika/web использует внутренний механизм упаковки для экспорта зависимостей npm, изначально поддерживаемых сетью, что является основной причиной, по которой многие из нас в первую очередь используют инструменты упаковки!

С @pika/web все хлопоты по созданию пакетов ложатся на этот инструмент времени установки. Пока вы этого не хотите, вам не нужно читать ни одной строки кода конфигурации инструмента упаковки. Но опять же, вы, конечно, можете продолжать использовать другие инструменты, которые вам нравятся: те, которые улучшают процесс разработки (Babel,TypeScript) или оптимизированного продукта (Webpack,Rollup).

Это принцип @pika/web: упаковывайте как хотите, а не обязательно.

截图：源码可见

ПС: о да,Я вижу, исходный код вернулся!

представление

Установка каждой зависимости как @pika/web (как один файл JavaScript) даст вам огромный прирост производительности по сравнению с тем, как большинство сборщиков устанавливают: кэширование зависимостей. Когда вы упаковываете все зависимости в один огромныйvendor.jsфайл, каждый раз, когда вы обновляете зависимость, вы должны заставить пользователя повторно загрузить весьvendor.js. И если используется @pika/web, обновление пакета зависимостей не заставит пользователя повторно кэшировать все зависимости.

@pika/web поможет вам избавиться от этих тормозов производительности, вызванных упаковщиками.Избыточный идентичный код в нескольких связанных файлах,Медленная загрузка в верхней части страницы из-за бесполезного или неактуального кода,Яма и ошибка, вызванные экологическим обновлением Webpack...все эти статьи и инструменты свидетельствуют о том, что люди делают все возможное, чтобы справиться с побочными эффектами упаковочных инструментов.

Чтобы было ясно, исходный код без упаковки не всегда идеален. С точки зрения эффекта сжатия при передаче по сети большие файлы JavaScript лучше, чем маленькие и детализированные файлы. пока вHTTP/2По протоколу браузер тратит больше времени на разбор запроса на импорт нескольких небольших файлов, и только после разбора может отправлять последующие запросы.

Это требует, чтобы вы сбалансировали производительность, эффективность кэширования и сложность, которые вы можете принять. Опять же, это дух @pika/web: упаковывайте как хотите, а не обязательно.

一堆乐高积木

Стратегия веб-разработки Пика

@pika/web полностью изменила то, как мы занимаемся веб-разработкой. Вот что мы построилиpika.devпроцесс, мы настоятельно рекомендуем вам в 2019 году использовать @pika/web для помощи в разработке вашего следующего веб-приложения:

  1. Начиная новый проект, пока не внедряйте инструменты упаковки. Пишите код в современном синтаксисе ESM и используйте @pika/web для установки зависимостей npm, которые запускаются непосредственно в веб-среде. Никаких инструментов не требуется.
  2. Вы можете добавить инструменты в любое время. Если требуется надежный механизм типизации, добавьтеTypeScript; если вы хотите использовать экспериментальные функции JavaScript, добавьтеBabel; если вам нужно минимизировать код JavaScript, добавьтеTerser. Прошло больше полугода,pika.devПроцесс разработки на данном этапе все еще идет гладко.
  3. Когда вы почувствуете необходимость и у вас будет время использовать сборщик, попробуйте добавить в свой проект простой сборщик. Проверьте, как это работает. Вышеуказанный фолд загружается быстро? А второй экран? Если все в порядке, договаривайтесь!
  4. По мере продвижения процесса разработки конфигурация инструмента упаковки постоянно оптимизируется.
  5. Как только вы уложитесь в бюджет, наймите эксперта по Webpack. поздравляю! Если у вас есть ресурсы, чтобы нанять эксперта по Webpack, с вами официально покончено.

Хотите увидеть несколько примеров? Есть там!

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из ИнтернетаНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории