Зачем нужен вебпак простым языком?

Прочитав статью на хабре, сделал вывод, что вебпак нужен для обеспечения модульности в js проекте. Но ведь в es6 появилась возможность импорта модулей, необходимость у вебпака пропадает. Можно ведь написать много модулей, импортировать в main.js и описать логику взаимодействия там. Объясните пожалуйста, возможно я неправильно понял что-то
  • Вопрос задан
  • 631 просмотр
Пригласить эксперта
Ответы на вопрос 4
sfi0zy
@sfi0zy
Creative frontend developer
Вебпак - сборщик. Может взять много файлов и собрать в один. Ну или в несколько, как мы настроим. В js действительно есть модули, которые как бы уже нативно работают в современных браузерах, но есть ряд проблем:

  • Файлов с кодом может быть много. Сотни. Если использовать нативные импорты и загружать сотни файлов в браузер одновременно - накладные расходы будут заметными. Было бы хорошо уменьшить количество файлов. Плюс там могут быть не только скрипты, но и другие файлы, которых тоже может быть много.
  • Большое количество инструментов были написаны еще до появления нативных модулей в JS. Они все еще работают, выполняют свои задачи, но простым словом import их не импортировать. Там очень разные чудеса встречаются. Придумывать для каждого инструмента персональный костыль, как его импортировать, вроде как не хочется.
  • К предыдущему - иногда удобно в скрипты на JS импортировать что-то не на JS из отдельных файлов. В контексте моей работы - шейдеры на GLSL. Их нельзя просто так нативным import загрузить.
  • Часть зависимостей мы ставим с помощью npm. Это удобно. Но мы легко получаем папку node_modules на сотни мегабайт, при том, что в нашем проекте реально используется пара файлов оттуда. Загружать все это целиком на сервер - зачем? Ставить зависимости, а потом копировать нужные файлы откуда-то из глубин node_modules к себе в проект? Можно, но не то, чтобы удобно. Обновлять сложно будет, да и действий лишних что-то много.
  • Не всегда нам нужен полный функционал инструментов, которые мы используем. Часто в пример приводят lodash. Там много готовых функций на разные случаи жизни, но все используются редко. Было бы прям здорово в браузер загружать только то, что там на самом деле будет использоваться. А то, что не используется - не загружать.


Как-то так. То есть нативные модули - это здорово. Но они далеки от совершенства. Не все проблемы решают. Поэтому сборщики все еще актуальны. И будут актуальны еще долгое время.

Плюс webpack имеет возможность встроить в процесс сборки дополнительные процессы, которые долго делать руками. Код можно минифицировать. Уменьшит время загрузки страниц. Можно запустить w3c validator, stylelint, eslint, sonar и.т.д. - всякие проверялки, чтобы убедиться, что к пользователям улетит валидный код. Можно какие-то картинки сжать, сконвертировать в другие форматы. Можно typescript превратить в javascript, less, sass и.т.д. - в css. Много чего можно сделать. В целом сборщик сам по себе - это перпендикулярный ко всем этим процессам инструмент. И раньше люди использовали отдельный класс инструментов, чтобы запускать все это - таск раннеры. Grunt, gulp - вы скорее всего про них слышали. Можно писать npm-скрипты или даже по старинке делать makefile под сложную сборку. Но в webpack вроде как есть функционал плагинов, и можно эти процессы запускать и через него тоже. Вроде как он не для этого изначально придуман, но многие люди находят удобным иметь все в одном месте.
Ответ написан
Комментировать
imko
@imko
Senior Scratch Developer
Импорт будет довольно неудобным решением когда дело дойдет до сторонних пакетов и разворачивания на сервере. Либо ты копируешь файлы ручками и весь менеджмент зависимостей происходит у тебя в голове, либо ты должен будешь докидывать пакетный менеджер на сервере, ну пускай тот же npm, инициализировать там проект в понимании npm и гонять там все вои зависимости. При чем он должен быть как минимум достаточно свежей версии если ты используешь какие-нибудь "новомодные" вещи. В общем куча лишних проблем по сравнению с тем чтобы ты просто создал проект у себя, подкинул в нем зависимости и выгружал на сервер проссто один бандл которому наплевать что там происходит на сервере.
В случае с собственными модулями ты проигрываешь как минимум в объеме файлов, так как вебпаку, а на деле и очень много чему, можно поручить минифицировать скрипты
Есть еще такие интересные вещи как babel который сделает твой ну допустим ES6 код рабочим на калькуляторах которые умеют только в ES5 и много много интересной пре-обработки)
Ответ написан
Комментировать
@Kirill-Gorelov
С ума с IT
Помогает автоматизировать кучи рутинной работы.
При установки разных пакетов он может вычищать из кода console.log, проверять код линтером, миницифировать, объединять нужные файлы в один файл. Очень нужная вещь.
Ответ написан
Комментировать
LenovoId
@LenovoId
svg, css,js
К примеру:
Вы хотите на будущем сайте использовать webgl но не в чистом виде а к примеру в виде threejs
А так же какой то слайдер изображений
А так же какие то ещё примочки -- так вот этот webpack позволяет установить любую приблуду хитрым способом
Это примерно как все специи в одном месте
Хотя ни кто не запрещает установить из какого то там хранилища или подключать по ссылкам перед закрытием тега body или в head руками - но новые реалии таковы что надо пользоваться этой шляпой так как удобно
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы