Browserify против Webpack
Если вам нужна хижина, зачем начинать
с простой груды бревен?
В стране JavaScript никто не может быть королем надолго.
Буквально в прошлом году Grunt был фактически свергнут Gulp. И теперь, когда Gulp и Browserify наконец достигают критической массы, Webpack угрожает свергнуть их обоих. Есть ли действительно веская причина изменить процесс сборки внешнего интерфейса еще раз?
Давайте рассмотрим достоинства каждого подхода.
Browserify (и друзья…)
Browserify концептуально прост. Эй, видишь все эти крутые пакеты на npm? Позвольте мне завершить их, чтобы вы могли использовать их в браузере. Удобно. Спасибо Browserify! Но эта простота - его ахиллесова пята. Скорее всего, у вас есть длинный список других вещей, которые вам нужно сделать, например, минимизация, объединение, линтинг, запуск тестов и т. Д.
Конечно, у Browserify есть богатая экосистема преобразований, которая помогает добиваться цели. Но чтобы все это связать, вам нужно самостоятельно. Итак, вы собираетесь использовать инструмент автоматизации сборки JavaScript, такой как Grunt или Gulp. Эти инструменты отлично работают, но их правильная настройка требует много времени. После долгой работы с Grunt или Gulp вы начинаете осознавать длинный список вещей, которые вы делаете для каждого проекта. Разве не было бы неплохо начать с более мощного и самоуверенного инструмента, который сделал бы больше предположений о вашем процессе сборки?
Если вы думаете о процессе сборки как об уникальной бревенчатой хижине, тогда Browserify с Gulp / Grunt похож на начало здесь:
Webpack
Webpack решает проблему сборки более интегрированным и упрямым образом. В Browserify вы используете Gulp / Grunt и длинный список преобразований и плагинов для выполнения своей работы. Webpack предлагает достаточно мощности из коробки, что обычно не требует Grunt или Gulp. Ага, извините, этот блестящий новый навык, который вы только что освоили, уже почти бесполезен. Эээ… ура? Вздох. Добро пожаловать в жизнь на фронтенде.
Но послушайте, это цена прогресса. С помощью Webpack вы можете объявить простой файл конфигурации, чтобы определить процесс сборки. Ого, файл конфигурации? Да, если вы перешли с Grunt на Gulp, потому что предпочитаете код конфигурации, это может показаться шагом назад. Но конфигурация - не обязательно плохо.
Системы на основе конфигурации предпочтительнее императивных систем, если они заранее делают правильные предположения о ваших целях.
Я считаю, что Webpack именно этим и занимается. Webpack предполагает, что вам нужно переместить файлы из исходного каталога в целевой каталог. Предполагается, что вы хотите работать с библиотеками JavaScript в различных форматах модулей, таких как CommonJS и AMD. Предполагается, что вы захотите скомпилировать различные форматы, используя длинный список загрузчиков. Конечно, вы можете сделать все это через Browserify и Gulp, но вам придется делать больше проводки самостоятельно. И вы вручную соединяете две совершенно разные технологии.
Интегрированный характер Webpack действительно проявляется, когда вы рассматриваете истории для работы с другими ресурсами, такими как изображения и CSS. Webpack достаточно умен, чтобы динамически встраивать ваши CSS и изображения, когда это имеет смысл. Вы можете просто включить эти ресурсы, как сегодня делаете это с JavaScript. Хотите использовать CSS? Легкий:
require("./stylesheet.css");
Хм? Почему бы просто не ссылаться на CSS по-старому? Что ж, Webpack будет учитывать размер этого файла. Если он небольшой, он будет встроен в таблицу стилей! Если он длинный, он уменьшит файл и даст ему уникальное имя для очистки кеша. Та же история работает и с изображениями, используя плагин загрузчика URL.
img.src = require(‘./glyph.png’);
Webpack закодирует это изображение в формате base64, если оно достаточно маленькое и имеет смысл. Slick!
Поскольку Webpack полностью осведомлен о вашем процессе сборки, он может разумно разделить ваши ресурсы на пакеты. Это удобно для больших SPA. Вашим пользователям будут предоставляться только те файлы, которые им нужны для данной страницы, а не один монолитный файл JavaScript.
Наконец, если вы хотите быстро разрабатывать приложения без обновлений браузера, Webpack предлагает горячую замену модулей. Если вам довелось работать в React, вы можете использовать React Hot Loader. Да, у Browserify есть аналог, но, по моему опыту, реализация Webpack от @dan_abromov лучше. Поверьте мне, как только вы испытаете такую быструю разработку приложений обратной связи, как это, вы больше никогда не вернетесь:
Webpack предполагает, что вы хотите построить бревенчатую хижину. Итак, вы начинаете с настоящей кабины, а затем получаете инструменты, необходимые для ее настройки в соответствии с вашими потребностями.
Суть
Если вы предпочитаете явно настраивать небольшие одноцелевые инструменты с нуля, тогда вам больше подойдет Browserify с Gulp / Grunt. Первоначально Browserify легче понять, так как концептуальная площадь намного меньше - если вы уже знакомы с Gulp или Grunt. При использовании Gulp с Browserify итоговый процесс сборки может быть проще для понимания, чем эквивалентная сборка Webpack. Часто намерения более ясны. Богатая экосистема плагинов Browserify означает, что с достаточным количеством проводов вы можете сделать практически все, что угодно. Ах, проводка. Это большой недостаток. Чтобы все получилось, требуется много времени и отладки. Недавно я создал стартовый комплект для моего предстоящего курса Pluralsight по React и Flux. Он задействует некоторые технологии, специфичные для React, но удаление этих зависимостей тривиально, если вы просто ищете быстрый способ начать работать с Browserify и Gulp.
Но если вам удобно немного «волшебства» с помощью одного более самоуверенного инструмента, тогда Webpack может сократить время, необходимое для обеспечения надежного процесса сборки. Я обнаружил, что мои конфигурации Webpack обычно примерно в два раза меньше размера эквивалентного файла Gulp. Выигрыш заключается не только в меньшем количестве наборов текста - это также означает меньшее время, затрачиваемое на отладку вашей конфигурации.
Огромные файлы Grunt оттолкнули многих от идеи конфигурации. Но неудача Гранта заключалась не в настройке. Это было отсутствие мнения. Конфигурация - это не зло. Когда предположения верны, это мощная экономия времени.
Инструменты сборки не должны требовать индивидуальной сборки с нуля. Он должен предоставлять точки настройки, которые позволят вам справиться с некоторыми вещами, которые делают вас по-настоящему уникальным.
Готовы копать глубже?
Обновленная документация Webpack великолепна, но я предлагаю вместо этого прочитать Превосходное вступление Пита Ханта. Затем ознакомьтесь с разделом Создание среды разработки JavaScript на Pluralsight (бесплатная пробная версия), чтобы увидеть полную среду разработки, созданную с нуля с использованием Webpack.
Используете React? Ознакомьтесь с Создание приложений с помощью React и Redux в ES6.
Присоединяйтесь к Hacker News или Reddit
Кори Хаус является автором множества курсов по JavaScript, React, чистому коду, .NET и многому другому на Pluralsight. Он является главным консультантом в reactjsconsulting.com, архитектором программного обеспечения в VinSolutions, имеет звание Microsoft MVP и обучает разработчиков программного обеспечения на международном уровне таким методам разработки программного обеспечения, как фронтенд-разработка и чистое кодирование. Кори пишет в Твиттере о JavaScript и интерфейсной разработке как @housecor.
