Gulp vs Webpack
Всем привет, дорогие друзья! И снова в профессиональном сообществе не утихают споры, относительно того, какой инструмент использовать в работе. Сегодня речь пойдет о таких инструментах, как Gulp и Webpack. Мы, наконец-то, поставим точку в этом вопросе и, я надеюсь, больше не будем к нему возвращаться.
Сегодня я хотел бы показать вам, дорогие друзья, насколько это глупый и бестолковый спор по определению и сделать вывод по данной теме.
Не стоит забывать, что мир веб-разработки не делится на черное и белое. Кроме области дизайна и области программирования в сферическом вакууме, есть и другие области. Это, в первую очередь, разработка коммерческих проектов на CMS, заказная разработка, конвейерная разработка, огромный пласт индустрии, не нуждающийся в Вебпаке, как первостепенном инструменте, ведь здесь не идет речи о создании приложений. Окромя компаний, которые занимаются созданием SPA, работающие в команде над одним единственным проектом, есть и другие области, другие рынки. И начинающие разработчики, дизайнеры, начитавшись отзывов, насмотревшись на тренды, формируют неправильное понимание рынка инструментов, начинают использовать не то, что им нужно, боясь быть не актуальными, не современными. И это ловушка. Они видят популярность инструмента, абсолютно не понимая природы такой популярности и области применения. Будьте рациональны, дорогие друзья.
Webpack vs Gulp, внятно и понятно. Или для чего мне еще один мощный инструмент?
нужно ли мне использовать webpack с gulp или вовсе, только webpack
Есть конечно «плагины» для webpack добавляющие функциональность таск раннеров но как по мне это уже перебор.
имхо очередное хипстерское (nodejs) веяние.
Каждый год, стабильно, весь мир «внезапно» осознает что их текущий инструмент (выпущенный год назад) стал слишком «фу фу фу», и нужно срочно запилить что-то новое, чтобы все сказали «ах».
Подождем пока лет 5, пока всё это устаканится, и сформируется нормальный стек технологий для разработки.
Вячеслав Лебедев:
>Факты убедительнее для того, чтобы самому решить, стоит ли он времени на изучение.
Какие факты? Что это очередная поделка, от тех кто мыслит как на картинке ниже?
Я пользуюсь gulp. В свое время стоял выбор между gulp и grunt, мне по духу больше пришелся gulp.
Менять его на что-то новое. зачем? Он полностью устраивает по своему функционалу.
А менять инструмент только ради моды. ну вам виднее.
D’ Normalization: я тоже был примерно такого же мнения, webpack смотрится слегка противоестественно. Но по итогу я решил попробовать и пока доволен, так как он решил целую гору моих проблем со сборкой проектов.
А для простого сайтика я бы webpack не брал конечно. Хотя сайтики разные бывают.
Вячеслав Лебедев: решает конечно, у меня все проекты на ES6 за последние пол года (чуть меньше пожалуй).
Пока спасало только то что в ангуляре есть свои модули, но иногда всеравно случаются косяки связанные с ресовом зависимостей и т.д.
Так же щаблоны. С gulp я собирал шаблоны в templateCache и не парился, с webpack я тупо импортирую их внутрь компонентов (шаблоны только для них) и далее с ними орудую. А так как я еще и jade использую то это все просто дико удобно.
webpack выдерет из core-js только те полифилы которые реально мне нужны (так как я явно прописал зависимость от оных). Это как бы и с другими бандлерами работает, тут просто преимущество бандлеров над тупой конкатенацией. С gulp (имею в виду без бандлинга) же мне пришлось бы подключать весь core-js или лепить кастыли.
Какую систему сборки FroneEnd’a выбрать? Grunt, gulp или webpack?
В общем-то, webpack немного в другой весовой категории, grunt/gulp инструменты более широкого назначения. Но! webpack покрывает, наверное, 90% задач, обычно возлагаемых на таск-раннеры. 7.5 оставшегося покрывают npm-скрипты, ну а 2.5 — сложные кейсы, где без раннера уж никак:)
grunt все еще вполне рабочий инструмент, и, по моему мнению, его конфиги куда более читаемы, чем у gulp, но реальность такова, что по работе вы скорее всего столкнетесь с проектом на gulp или вообще на одном webpack.
Webpack сейчас встречается довольно часто, так что какой-то конфиг собрать нужно, но с другой стороны сильно париться по этому поводу нет смысла. В основном, главное, чтобы проект работал. Есть готовые конфиги и бойлерплейты и нет ничего плохого в том, чтобы ими пользоваться.
Gulp vs Grunt — Gulp вроде очевидный выбор будет, хотя grunt также используется. А что касается актуальности, то известные front-end разработчики рекомендуют переходить на npm скрипты.
В общем-то, если работа не диктует стек технологий сейчас, то выбор за Вами. Что больше нравится, то и берите.
Webpack vs Gulp
У тебя на календаре какой год?
Один вопрос начинающего (но подающего надежды) фронтэндщика более опытному:
вот неужели каждый год нужно менять то, что прекрасно отображает нужный нам контент? Зачем ежегодно все ломать и переписывать на новые *.js? новые *css?
Год 2016, TypeScript и CoffeeScript пока лучшие языки, компилируемые в JS
Вот просто с моей позиции (отмечу еще раз, что я пока обучаю себя фронт-энд технологиям): есть некоторые базовые вещи, вроде html, css, js php/mysql. ну да, это уже back. Я конечно все понимаю, но различные обертки не явлюятся объектом великого поклонения. По крайней мере, они не должны быть таковыми, если честно.
Получается, что если ты в 2016 году якобы не гоняешь что-то сырое, но новомодное — ты уже не front-end developer?
Подскажи пожалуйста, насколько необходимо при изучении html/css углубляться в эти gulp/webpack?
читать под под тему Терминатора ( https://www.youtube.com/watch?v=pVZ2NShfCE8 ) предварительно защемив прищепкой нос
1. Потихонечку пытаются запилить CoffeeScript6, таргетом которого является ES6
2. Handlebars хватит всем
3. Я пользуюсь Sass с PostCSS
Sass из-за синтаксиса и миксин, PostCSS из-за Styleguide и других удобный плагинов, напрмер postcss-animate или postcss-circle
webpack — бандлер, gulp — билд-система, как их можно сравнивать?
Получается, что если ты в 2016 году якобы не гоняешь что-то сырое, но новомодное — ты уже не front-end developer?
Нет. Но дело в том, что ECMAScript 2015 — не сырой, он стандарт. Даже ECMAScript 2016 уже стандарт. И да, они капитально облегчают жизнь по сравнению с тем же кофе.
PostCSS тоже не сырой, и тоже он капитально упрощает всё по сравнению с less. Плюс на нём реализовано то, что будет поддерживаться браузерами в будущем без костылей, а у less никакого будущего нет.
Смысла начинать новый проект на coffee/less сейчас нет.
1. Потихонечку пытаются запилить CoffeeScript6, таргетом которого является ES6
О, правда? А где его можно посмотреть-потыкать? Асинк там будет?
Честно — не пользовался, без комментариев.
3. Я пользуюсь Sass с PostCSS
Sass из-за синтаксиса и миксин, PostCSS из-за Styleguide и других удобный плагинов, напрмер postcss-animate или postcss-circle
Автопрефиксер не забудь, который тоже плагин к postcss. А какой конкретно синтаксис sass тебя интересует? По поводу миксинов — для postcss есть реализация @apply: https://github.com/pascalduez/postcss-apply.
Если ты из этой связки Sass выкинешь — ты ничего не потеряешь =).
А теперь запихни всё это (и заодно пару лёгких фонов в png/jpg) в твой bundle.js.
Вы так говорите как будто это плохо.
Чем это принципиально отличается от склеивания всего кода в один min.js?
Sass у меня Node-sass, который биндится к libsass, который на плюсах
Ненависть. Это та самая хрень, которая качает бинари с сервера и постоянно ломается при обновлении версии ноды.
Ноду я обновляю не так часто, ну и собирается на Core2Duo все это где-то минуту-две
Несложно подождать раз в месяц
Imagemin вообще тащит несколько бинарей
Зато скорость
А для PostCSS есть плагин less.js, который собирает less, и скорость выше обычного less.js 🙂
ну и собирается на Core2Duo все это где-то минуту-две
Оно не собирается, оно качает готовые бинарники с сервера емнип.
c less давно перелезли на scss, а потом с scss — на postcss.
Пиши на VanillaJS — никаких проблем не будет.
CSS тоже не так уж сложно собирать без всех этих собиралок, просто надо более ответственно подходить к дизайну архитектуры.
Есть preact в 3кб, но я бы не рискнул пускать его в продакшн, по крайней мере без параноидального покрытия тестами.
Gulp + Webpack или просто Webpack?
Я вижу, что люди используют gulp с webpack. Но потом я прочитал, что webpack может заменить gulp? Я совершенно запутался. кто-нибудь может объяснить?
в конце концов я начал с gulp. Я был новичком в современном интерфейсе и просто хотел встать и быстро бежать. Теперь, когда у меня ноги совсем мокрые после более чем года, я готов переехать в webpack. Я предлагаю тот же маршрут для людей, которые начинают в той же обуви. Не говорю, что вы не можете попробовать webpack, но просто говоря, если это кажется сложным, начните с глотка. в этом нет ничего плохого.
Если вы не хотите глотать, да, есть ворчание, но вы также можете просто указать команды в своем пакете.json и вызовите их из командной строки без бегуна задач, чтобы сначала встать и запустить. Например:
5 ответов
. и вот пример использования webpack из задачи gulp. Это идет дальше и предполагает, что ваша конфигурация webpack написана в es6.
НПМ скрипты может сделать то же самое, что и gulp, но примерно в 50 раз меньше кода. Фактически, без кода вообще, только аргументы командной строки.
например, описанный вами вариант использования, в котором вы хотите иметь другой код для разных сред.
С Webpack + npm скрипты, это так просто:
из-за прохлады сценариев NPM он позволяет легко цепляться, подобно тому, как gulp делает потоки/трубы.
на pre и post префиксы сообщают NPM, какой заказ выполнить.
попробуйте сделать то же самое с gulp. У тебя будет ждать, пока кто-то придет и напишет оболочку глотка для родной программы, которую вы хотите использовать. Кроме того, вам, вероятно, придется написать такой запутанный код: (взято прямо из angular2-seed РЕПО)
код разработки Gulp
производственный код Gulp
фактический код gulp намного сложнее, чем это, так как это только 2 из нескольких десятков файлов gulp в РЕПО.
Итак, какой из них вам легче?
на мой взгляд, сценарии NPM намного превосходят gulp и grunt, как по эффективности, так и по простоте использования, и все интерфейсные разработчики должны рассмотреть возможность использования его в своем рабочем процессе, потому что это большая экономия времени.
обновление
есть один сценарий, с которым я столкнулся, где я хотел использовать Gulp в сочетании со сценариями NPM и Webpack.
когда мне нужно сделать удаленной отладки на устройстве iPad или Android, например, мне нужно запустить дополнительные серверы. В прошлом я запускал все серверы как отдельные процессы, из IntelliJ IDEA (или Webstorm), что легко с конфигурацией запуска «Compound». Но если мне нужно остановить и перезапустить их, было утомительно закрывать 5 разных вкладок сервера, плюс вывод был распространен по разным окнам.
одно из преимуществ глотка что может приковать полностью выход из отдельных независимых процессов в одно окно консоли, которое становится родительским для всех дочерних серверов.
поэтому я создал очень простую задачу gulp, которая просто запускает мои сценарии NPM или команды напрямую, поэтому все выходные данные отображаются в одном окне, и я могу легко завершить все 5 серверов сразу, закрыв окно задачи gulp.
поэтому я в основном использую сценарии NPM для всех своих задач, но иногда, когда мне нужно запустить сразу несколько серверов, я запускаю свою задачу Gulp, чтобы помочь. Выбрать правильный инструмент для правильной работы.
Я предлагаю вам прочитать эти статьи, сравните их в глубина.
я использовал оба варианта в разных проектах.
и они оба отлично работают. И я думаю, все сводится к тому, насколько сложна твоя задача, и насколько ты хочешь контролировать свою жизнь. конфигурация.
но если у вас очень сложный рабочий процесс, и вы хотите иметь больше контроля над своей конфигурацией ( потому что это кодирование), вы можете пойти на маршрут gulp.
но по моему опыту, экосистема webpack предоставляет более чем достаточно плагинов и загрузчиков, которые я понадобится, и поэтому я люблю использовать минимальный подход, если нет чего-то, что вы можете сделать только залпом. А также, это сделает вашу конфигурацию проще, если у вас есть одна вещь меньше в вашей системе.
честно говоря, я думаю, что лучше использовать оба.
мне все еще нужно найти достойное решение для упаковки css с webpack, и до сих пор я доволен использованием gulp для css и webpack для javascript.
понятия Gulp и Webpack совершенно разные. Вы скажите Gulp как чтобы собрать интерфейсный код шаг за шагом, но вы говорите Webpack что вы хотите через файл config.
вот короткая статья (5 минут чтения), которую я написал, объясняя свое понимание различий: https://medium.com/@Maokai/compile-the-front-end-from-gulp-to-webpack-c45671ad87fe
наша компания переехала из Gulp в Webpack в прошлом год. Хотя это заняло некоторое время, мы выяснили, как переместить все, что мы сделали в глотке в Webpack. Поэтому для нас все, что мы сделали в Gulp, мы также можем сделать через Webpack, но не наоборот.
на сегодняшний день я бы предложил просто использовать Webpack и избегать смеси Gulp и Webpack, поэтому вам и вашей команде не нужно учиться и поддерживать оба, особенно потому, что они требуют очень разных мыслей.