СТАТЬЯ KOBEZZZA.LAB
Почему еще не поздно изучить webpack
10 лет
В следующем году webpack будет отмечать свое 10-летие. Это довольно внушительный срок для инструмента разработки, особенно в быстроизменяющемся мире фронтенда.
Мы привыкли к тому, что новые фреймворки, библиотеки и инструменты непрерывно вытесняют друг друга, постоянно появляются более быстрые, удобные и привлекательные технологии, в то время как старые быстро уходят в небытие. Так было с backbone, ember, grunt…
Этот список можно продолжать довольно долго. В наши дни, если вы столкнетесь с такой технологией, скорее всего, это будет в устаревшем проекте, который долго не обновлялся и нуждается в рефакторинге. Вряд ли сегодня разработчики будут изучать backbone и указывать его в своем резюме.
Обычно, старая технология уходит в историю, когда у нее появляется преемник, который сильно лучше в каком-то аспекте или во всем сразу: в удобстве, скорости, возможностях, простоте освоения.
Так например было с grunt: когда появился gulp, то grunt почти сразу же отошел на второй план. Gulp был лучше во всем: быстрее (из-за использования виртуальной файловой системы vinyl fs), удобнее (из-за понятного и лаконичного конфига) и очень простым для освоения.
Однако Webpack до сих пор с нами и живее всех живых. Почему?
Этот список можно продолжать довольно долго. В наши дни, если вы столкнетесь с такой технологией, скорее всего, это будет в устаревшем проекте, который долго не обновлялся и нуждается в рефакторинге. Вряд ли сегодня разработчики будут изучать backbone и указывать его в своем резюме.
Обычно, старая технология уходит в историю, когда у нее появляется преемник, который сильно лучше в каком-то аспекте или во всем сразу: в удобстве, скорости, возможностях, простоте освоения.
Так например было с grunt: когда появился gulp, то grunt почти сразу же отошел на второй план. Gulp был лучше во всем: быстрее (из-за использования виртуальной файловой системы vinyl fs), удобнее (из-за понятного и лаконичного конфига) и очень простым для освоения.
Однако Webpack до сих пор с нами и живее всех живых. Почему?
Альтернативы
За все эти годы у webpack появилось множество альтернатив: rollup, parcel, esbuild, turbopack, snowpack, rspack…
Однако ни один из этих инструментов так и не смог заменить webpack.
Каждая альтернатива webpack пыталась пересмотреть подход к процессу сборки и позиционировала себя как замена webpack + killer feature.
Например killer feature Parcel был подход zero-config. Для того чтобы собрать код, не нужно писать монструозный конфиг, просто создаете src/index.js и пишете npm run build, вуаля, все собирается. Больше не нужно тратить дни на изучение документации, чтобы написать конфиг для сборки вашего hello world.
А вот killer feature Rollup был tree-shaking. В то время это была совсем новая идея и webpack так не умел. Tree-shaking был особенно полезен для разработчиков библиотек, так как позволял генерировать намного более меньший по размеру бандл.
Тем не менее, все эти инструменты так и остались лишь альтернативами, а webpack вбирал в себя лучшее от конкурентов, поэтому все эти возможности теперь есть и у webpack (zero config, tree-shaking). Спасибо огромному коммьюнити вокруг webpack и его мейнтейнерам.
В итоге webpack до сих пор развивается, поддерживается и является промышленным стандартом разработки.
Каждая альтернатива webpack пыталась пересмотреть подход к процессу сборки и позиционировала себя как замена webpack + killer feature.
Например killer feature Parcel был подход zero-config. Для того чтобы собрать код, не нужно писать монструозный конфиг, просто создаете src/index.js и пишете npm run build, вуаля, все собирается. Больше не нужно тратить дни на изучение документации, чтобы написать конфиг для сборки вашего hello world.
А вот killer feature Rollup был tree-shaking. В то время это была совсем новая идея и webpack так не умел. Tree-shaking был особенно полезен для разработчиков библиотек, так как позволял генерировать намного более меньший по размеру бандл.
Тем не менее, все эти инструменты так и остались лишь альтернативами, а webpack вбирал в себя лучшее от конкурентов, поэтому все эти возможности теперь есть и у webpack (zero config, tree-shaking). Спасибо огромному коммьюнити вокруг webpack и его мейнтейнерам.
В итоге webpack до сих пор развивается, поддерживается и является промышленным стандартом разработки.
Мощь
Но почему так? Какой нибудь esbuild, судя по бенчмаркам, сильно быстрее и написан на go с упором на использование многопоточности. Почему большинство крупных проектов до сих пор используют webpack?
Ответ довольно простой: потому что webpack умеет всё и ни один сборщик не способен заменить его в полной мере.
Графически это можно изобразить так:
Ответ довольно простой: потому что webpack умеет всё и ни один сборщик не способен заменить его в полной мере.
Графически это можно изобразить так:
Webpack diagram
Если вы используете webpack вам открыта невероятная мощь, вы можете вмешаться в любой этап сборки.
Поменять алгоритм формирования модулей в чанки? Почему нет.
Вмешаться в парсинг js кода изменив поведение import? Тоже можно
Также вебпак один из пионеров во внедрении WebAssembly, он поддерживает самый современный стандарт webassembly и без труда может включить .wasm в ваш бандл.
Ни одна из альтернатив webpack не дает столько возможностей.
Поменять алгоритм формирования модулей в чанки? Почему нет.
Вмешаться в парсинг js кода изменив поведение import? Тоже можно
Также вебпак один из пионеров во внедрении WebAssembly, он поддерживает самый современный стандарт webassembly и без труда может включить .wasm в ваш бандл.
Ни одна из альтернатив webpack не дает столько возможностей.
Жизненный цикл проекта
“И все же, я могу взять какой нибудь CRA и написать на нем проект за пару часов, не тратя ни секунды на настройку всей этой чепухи со сборкой! Да и вся эта мощь мне ни к чему, я просто хочу вывести hello world”.
Это правда. Если вы только начинаете новый проект, то лучше взять готовый starter-kit, который делает основные вещи более-менее оптимальным образом и не тратить время на первоначальную настройку (скорее всего на начальном этапе у вас и не будет понимания как настроить эти вещи самым оптимальным образом).
Но starter-kit на то и starter. Возможно когда нибудь, ваш проект перерастет дефолтный конфиг и вам нужно будет сделать что-то очень хитрым образом и той степени свободы настройки, которую вам позволяет ваш starter-kit, не хватит.
Вы можете использовать более современные сборщики вместо webpack, но вы можете попасть в ситуацию, с которой ваш инструмент справиться не сможет и при этом вы будете знать, что webpack на это как раз способен.
Например, ваш проект стал очень большим и вы хотите поддерживать старые браузеры, потому что это существенная часть аудитории.
Вы используете esbuild, потому что он быстрый и классный и тут оказывается, что esbuild не умеет собираться в es5.
Или вы захотите собрать ваше приложение в качестве Electron приложения, но вы используете parcel, а он плохо это умеет.
Если вы будете работать в действительно крупном проекте, то увидите что он уже давно перерос стадию starter-kit и использует webpack на полную мощь: с кастомными плагинами/лоадерами, бандлингом в es5 и много еще чем, что скорее всего альтернативный инструмент попросту не умеет делать.
Но starter-kit на то и starter. Возможно когда нибудь, ваш проект перерастет дефолтный конфиг и вам нужно будет сделать что-то очень хитрым образом и той степени свободы настройки, которую вам позволяет ваш starter-kit, не хватит.
Вы можете использовать более современные сборщики вместо webpack, но вы можете попасть в ситуацию, с которой ваш инструмент справиться не сможет и при этом вы будете знать, что webpack на это как раз способен.
Например, ваш проект стал очень большим и вы хотите поддерживать старые браузеры, потому что это существенная часть аудитории.
Вы используете esbuild, потому что он быстрый и классный и тут оказывается, что esbuild не умеет собираться в es5.
Или вы захотите собрать ваше приложение в качестве Electron приложения, но вы используете parcel, а он плохо это умеет.
Если вы будете работать в действительно крупном проекте, то увидите что он уже давно перерос стадию starter-kit и использует webpack на полную мощь: с кастомными плагинами/лоадерами, бандлингом в es5 и много еще чем, что скорее всего альтернативный инструмент попросту не умеет делать.
Промышленный стандарт
Ранее я назвал webpack промышленным стандартом.
Стоит заметить, что это справедливо только для больших frontend проектов, которые являются конечными приложениями (с которыми непосредственно взаимодействует пользователь).
Стоит заметить, что это справедливо только для больших frontend проектов, которые являются конечными приложениями (с которыми непосредственно взаимодействует пользователь).
Есть один сценарий, в котором webpack проиграл: сборка библиотек.
Самые большие и распространенные библиотеки во frontend используют для сборки не webpack:
Rollup же напротив, много внимания уделяет именно сборке библиотек и самое главное имеет хороший tree-shaking, что позволяет генерировать меньший по объему код.
Многие разработчики, видя это, считают что rollup невероятно хорош, раз даже разработчики библиотек выбирают его. Однако не стоит заблуждаться, rollup хорош именно для сборки библиотек, в конечном проекте лучше все таки выбирать webpack.
Самые большие и распространенные библиотеки во frontend используют для сборки не webpack:
- Vue использует rollup + esbuild
- React использует rollup
- Svelte использует rollup + esbuild
Rollup же напротив, много внимания уделяет именно сборке библиотек и самое главное имеет хороший tree-shaking, что позволяет генерировать меньший по объему код.
Многие разработчики, видя это, считают что rollup невероятно хорош, раз даже разработчики библиотек выбирают его. Однако не стоит заблуждаться, rollup хорош именно для сборки библиотек, в конечном проекте лучше все таки выбирать webpack.
Итоги
Изучать webpack не поздно. Эти знания с большой вероятностью вам пригодятся и расширят ваши горизонты понимания возможностей того, как собирается код и как можно на это повлиять.
При этом количество разработчиков в средней команде, которые разбираются в процессе сборки проекта, стремится к 1-2 самым опытным разработчикам (обычно это сеньоры).
Давайте еще раз взглянем на граф возможностей:
При этом количество разработчиков в средней команде, которые разбираются в процессе сборки проекта, стремится к 1-2 самым опытным разработчикам (обычно это сеньоры).
Давайте еще раз взглянем на граф возможностей:
Webpack diagram
Даже если вы придете на проект, где используется не webpack, вам не составит никакого труда изучить тот же esbuild или rollup, ведь эти инструменты делают то же самое, что и webpack и работают по тем же самым принципам.
Не поддавайтесь хайпу, изучайте проверенные временем инструменты и да пребудет с вами база.
Не поддавайтесь хайпу, изучайте проверенные временем инструменты и да пребудет с вами база.
Если интересуешься темой
инфраструктуры, то не пропусти
инфраструктуры, то не пропусти
