Ха-ха, ну вы уже давно как матёрый разработчик)
У меня такой опыт мог бы сложиться, родись я хотя бы на пару лет пораньше. Нода появилась чуть раньше того момента, когда я нашёл первую работу по специальности) А вместе с ней пошли-поехали сборщики, фреймворки, пререндеринги и т.д.
Хотя с усами без ангуляров, реактов и вуёв я тоже экспериментировал, но исключительно на клиенте. Сейчас, конечно, всё это не особо актуально.
А сервера на C/C++ я вообще вживую ни разу не видел. Слышал только, что до появления PHP только на них и писали.
А так да, я понимаю, что были и раньше способы. Но сейчас они становятся «народными» и большее количество людей начинает их использовать.
Я о том, что просто нужно взвешивать целесообразность внедрения SSR с точки зрения трудозатрат. Чем сложнее проект и чем больше в нём legacy кода, тем больше человекочасов займёт внедрение SSR.
Про телевизор понял, нагдлядно.
А чем это не тоже самое?
Ну как минимум тем, что фронтенд и бэкенд не пересекаются и гораздо более явно разделены. Никто не «натягивает вёрстку», не переписывает стили под CMS/фреймворки, не решает проблем с SEO и т.д. и т.п. Каждый занят своим делом: фронтендщик — пишет стили, разметку и интерактив, бэкендщик — создаёт бизнес-логику и API для неё. Изоморфность же достигается сама собой благодаря одному человеку, который один раз настроил сборку и сервер для SSR, а также разъяснил немногочисленные особенности разработки фронтендщикам. У меня этого достичь с одним лишь PHP на сервере не получалось :)
SSR != изоморфность, но SSR — инструмент, позволяющий достичь изоморфности.
По первым двум абзацам. На самом деле просто надо взвешивать все за и против на конкретном проекте. Сложно говорить об этом всём абстрактно.
Я просто хотел показать, что есть другая сторона, которая тоже имеет право на существование.
Идея с автопереключением SSR и SPA. Интересно, но оно того стоит? Можно просто рендерить на сервере всегда, так как это никому не приносит неудобств, кроме сервера. А если сервер начинает от этого уставать, то можно кешировать. Да и на самом деле мне кажется, что в перспективе SSR сравняется по производительности с обычными шаблонизаторами, ведь по сути задача его сводится к тому, чтобы получить данные и запихать их в разметку. А весь интерактив начинает свою работу уже на клиенте.
Про SSR — как ни крути, а это не то же самое, что мы делаем при построении старого доброго бэкенда с шаблонизаторами, jQuery и пр. Это всё равно развитие (= эволюция), то есть слияние всего того, что было хорошо в SPA с тем, что было хорошо в MPA. Плюс это развитие идеи пререндеринга просто потому, что SSR лучше пререндеринга почти во всём.
Про SEO — да, я признаю, что это субъективно. И да, SSR решает все проблемы разом, с этим я вообще не спорил.
Я больше не буду приводить цитаты, а то слишком уж длинные комментарии получаются :)
Думаю, из контекста будет понятно, на что я отвечаю.
Статья конца 2013 года. Я не могу утверждать наверняка, потому что не имею такой статистики, но подозреваю, что ситуация сильно изменилась вместе с ростом качества, доступности и скорости интернета (много где появился 3G/4G, например), а так же падением популярности старых версий IE (УРА). Возможно, 0.2% людей с реально отключенным JS ещё остались, но цифра 0.9% скорее всего упала.
По поводу 3-секундного скрипта, кеша и доработок приложения — если применить код-сплиттинг и определённым образом настроить вебпак, то все эти проблемы решатся. Но, конечно, глупо спорить с тем, что SSR так или иначе повысит скорость отображения контента. Просто, опять же, я к тому, что это решаемо и без SSR.
Cordova и пр. — тут я просто, если честно, не понял, к чему была поднята тема. А так да, со всем согласен :)
Phantom/prerender решают те же проблемы, согласен. Но я считаю SSR своего рода эволюцией пререндеринга. Это более разумное решение, которое работает значительно быстрее + имеет хороший потенциал для оптимизации + с ним удобнее работать на сервере в целом (подключать какую-то аналитику, кешировать и прочее). То есть если есть равнозначный выбор между пререндерингом и SSR, то было бы глупо выбирать первое. Но для существующих проектов с большим количеством кода пререндеринг может быть единственным решением.
А SEO — да, главный аргумент лично для меня. Просто потому, что это единственный вариант писать код «без костылей» и не жертвовать SEO (ну, есть ещё пререндеринг, но свою позицию относительно него я уже описал). Но то, что он параллельно решает ряд других проблем или улучшает какие-то показатели — определённо, приятный бонус.
Опыт же крупных проектов по выпиливанию/впиливанию чего-то — думаю, не совсем об этом. Технологии в вебе, особенно на фронтенде, меняются с невероятной скоростью. С ними же растут потребности, критерии качества, размеры js/css файлов,… Появление проблем из-за этого всего неизбежно с любыми технологиями.
Ну во-первых, около 1% юзеров вообще не получают JS. Делал доклад на эту тему, могу найти пруф.
В каком плане не получают? Доклад посмотреть было бы интересно, да!
«Видишь суслика, а он есть» ...
Я и не утверждал, что таких людей нет. Просто их недостаточно много для того, чтобы только ради них внедрять SSR. Конечно, всё будет зависеть от ЦА, но сложно представить такую ЦА, где достаточно большая доля людей без JS.
Это вы так сейчас неудачно пошутили? А можете пояснить почему же для SPA — это мелочь? ...
Нет, я серьёзно :) По двум причинам:
— скрипты грузятся один раз и кэшируются, то есть при всех последующих загрузках страницы проблем с этим не будет
— в SPA нет явных физических переходов между страницами сайта/приложения, поэтому потерпеть придётся всего один раз при открытии ресурса
Скрипты для сложных веб-приложений стали весить хренову тучу Мб…
нужно помнить что у вас есть всего 3 секунды, чтобы их заинтересовать
Это легко решается с помощью code splitting в webpack. То есть я не утверждаю, что проблемы нет, но есть более простые альтернативные способы их решения. SSR же — стрельба из пушки по воробьям.
Есть всякие Cordova/Electron/etc. и у них немного разные принципы к построению приложения относительно того же веба ...
Ну для таких целей подозреваю (не уверен), что можно просто делать разные сборки одного и того же приложения. К тому же они будут существовать параллельно с SSR, так как они вообще не имеют прямого к нему отношения. Ну и JS эти технологии прекрасно исполняют (иначе зачем они вообще), так что это принципе не аргумент в данном случае.
Да если рассуждать как вы, то SPA и SEO не нужно. Вы же наверное из тех, кто делает SPA только для кабинетов и админок.))))
Зачем же вы так меня обижаете :(
Я, наоборот, топлю за то, чтобы вообще любой проект сложнее бложика делать как SPA, а проблемы с SEO решать серверным рендерингом. При должной квалификации разработчиков в человекочасах потерь не будет (скорее наоборот), зато UI/UX получит значительный прирост.
Вообще, мой посыл не совсем в том, что не надо использовать SSR для чего-либо кроме SEO. Я говорю о том, что все остальные проблемы, которые решает SSR не стоят того, чтобы его внедрять, так как можно обойтись меньшей кровью.
Но с другой стороны SSR достаточно один раз настроить и потом везде использовать без дополнительных затрат, и все новые проекты лично я бы всегда делал с поддержкой SSR, так как мне, как разработчику, у которого есть для этого готовое решение, это ничего не стоит.
Другое дело пересаживать на SSR какой-то существующий фронтенд, тут всё значительно сложнее.
Не знаю, в каких случаях реально нужно обходиться без JS. Сейчас даже на недорогих моделях телефонов можно открыть сайт на фреймфорке и без особых тормозов с ним работать.
Environment agnostic — тоже не сказал бы. Всё равно для чтения HTML нужен браузер, который поддерживает также и JS, так что никаких дополнительных ограничений, связанных со средой выполнения, JS не накладывает. Я ни разу не встречал живого человека, который был бы одновременно в своём уме и выключал JS в браузере :)
Единственное, с чем глупо не согласиться — скорость первичной загрузки. Но это в случае с SPA мелочь, ради которой не стоит заморачиваться с SSR.
В общем, по моему мнению SEO — единственная причина использовать SSR. Я пытался придумать другие реально веские причины для этого, но так ни к чему и не пришёл.
Если исходить из вашего примера, то да, SSR должен отдавать только контент для анонимусов, всё остальное определяется/грузится уже на клиенте.
Мало того, можно целые разделы рендерить исключительно на клиенте, типа тех же личных кабинетов со своими внутренними роутами (на Vue это делается очень просто). С сервера в таком случае приходит пустая страница или, скажем, какой-нибудь индикатор загрузки, а на клиенте уже получаем информацию о текущем пользователе (скажем, в хуке beforeMount или mounted, которые на сервере не вызываются) и выводим в зависимости от его наличия форму для входа или непосредственно личный кабинет (<router-view />).
В общем-то это всё, что нужно понимать, статья тут, мне кажется, не нужна :)
Это, к сожалению, неизбежно, так как нужно уметь исполнять то же самое, что и браузер, а тут выбор невелик — только nodejs. Выход — писать на js вообще всё, в частности и API.
Почему же по-своему, я на неё и опирался, когда всё это делал. Просто там было далеко не всё, что нужно мне, да и вообще в любом более-менее серьёзном проекте. Не описано, как подмешивать состояния компонентов (только vuex state), ни слова про взаимодействие с API и т.п.
Правда, этого всего и не должно быть в документации, так как её цель — описать возможности, а не давать готовый код. Второе как раз и есть задача, которую я пытаюсь решить в этой статье.
Но было бы правильно оставить в статье ссылку на документацию, это я сделаю в ближайшее время.
Ну если сайт не предполагал SSR при разработке, то иного пути просто нет, придётся использовать пререндеринг. Ну или переписать сайт :)
Я имел в виду, что брать пререндеринг при разработке нового SPA — это устаревший подход.
Ну на самом деле для SEO по сути кроме разметки ничего не нужно, а с этим SSR как раз и справляется, он для этого и создан. Так что да, с оптимизацией это не просто помогает, а является одним из способов оптимизировать в принципе :)
Есть ещё пререндеринг, но серверный рендеринг — это его эволюция, то есть пререндеринг просто можно считать устаревшим подходом.
Насчёт интерпретации js поисковиками я слышал, но я очень скептически к этому отношусь. Представьте, сколько мощностей нужно задействовать, чтобы за адекватное время запустить каждый говносайт со всем его кодом в масштабах гугла. Ну и плюс слышал, что эта дрянь пока что не очень хорошо работает — старый добрый HTML всё равно надёжнее. По крайней мере ближайшие лет 5 точно (имхо).
Так SSR же никак не ограничивает количество бандлов — их хоть 100 может быть. Так что да, легко можно использовать такой подход. Не уверен, правда, что HtmlWebpackPlugin получится под это настроить.
Во-первых, какой такой КАЖДЫЙ раз? Таски пишутся один раз и потом, возможно, немного изменяются и дополняются, и то со временем все реже и реже. Во-вторых, я и пытаюсь донести мысль, что гадать не нужно, так как все это легко запоминается (по крайней мере не сложнее, чем названия всех необходимых модулей для сборки и код для их запуска). В-третьих, npm scripts — это и есть специальный инструмент. Да, он проще, чем модули, но тем не менее. В-четвертых, взгляните на мой первый комментарий, там ясно видно, что сервер скрипты тоже умеют запускать. Ну а сборка из памяти или уже реализована на уровне модулей, которые запускаются у меня из командной строки, или работают слишком быстро, чтобы я это заметил — точно сам не знаю. Хотя, возможно, на очень большом количестве файлов выигрыш будет заметен. Но как минимум для сборки js есть watchify, который вне зависимости от количества и сложности сборки на лету собирает только изменившийся файл, что в итоге занимает до 20 мс.
Строка stylus assets/styles/main.styl -w -r -u kouto-swiss -o public/assets/main.css лично мне вполне понятна. Как я говорил выше, флаги -w и -o являются, скажем так, общепринятыми. Флаг -u тоже очевиден, поскольку слово kouto-swiss после него можно интерпретировать однозначно — это зависимость. Делаем вывод, что -u — это что-то типа use и запоминаем этот флаг таким образом как минимум надолго. Остается флаг -r, который похожими интеллектуальными усилиями можно интерпретировать как resolve, то есть разрешать относительные пути для файлов исходников.
Ну а если даже такие усилия делать лень, то для каждой буквы есть соответствующий более длинный аналог: --watch, --resolve-url, --use, --out. И что же тут «плохо читается»?
Ну как минимум в stylus (уверен, что и у других препроцессоров такая возможность есть) автопрефиксы можно расставлять без дополнительных специализированных модулей с помощью kouto-swiss. А в статье показывается, как можно делать. Понятно, что это не безоговорочное руководство к действию, но возможность есть делать все, что необходимо. При желании более красивым способом.
1) Так кто мешает не подчеркивание использовать, а просто папку? Например, папка styles/main для основных файлов, все остальное в styles. Ну и как угодно по-другому. Да, скриптами сложно сделать именно как у вас, но зачем делать свалку файлов в одном месте, когда можно их распределить по смыслу без ущерба удобству?
2) Значит, в вашем случае такой подход, действительно, неприменим. Я не утверждал, что npm scripts полностью заменяет таск-менеджер — я говорил, что для простых (и наиболее распространенных) случаев он подходит больше.
3) Да, в таких случаях разумнее запускать отдельные js-файлы с реализацией задач через код, но что в этом плохого? Насколько я знаю, многие и с таск-менеджерами делают то же самое, вынося отдельные таски в отдельные файлы. Да и зачем задачи подгружать автоматом? Таски пишутся один раз и потом довольно редко изменяются, так что это не такая уж и проблема. Да и если это вдруг становится проблемой, то вы правильно заметили, что можно написать свой автолоадер для этого. И это совсем несложно.
4) Для человека, который не знает ни gulp, ни grunt (и т.п.), ни npm scripts совершенно нет никакой разницы. Но с тем, что модули таск-менеджеры популярнее, чем npm я согласен, так что в проекте, где все разрабы уже что-то знают, наверно, проще пользоваться модулем.
5) Стандартными — никак, но есть по крайней мере один модуль parallelshell (наверняка есть и другие, я не искал), задача которого как раз запускать в командной строке одновременно несколько процессов.
Таск-раннеры громоздки, их эффективность растет со сложностью задач, но их не стоит пихать всегда и везде. И агитирую я не переезжать на npm scripts, а воспринимать его как альтернативу.
Ну и, конечно, я до сих пор не могу отойти и понять, как такое можно всерьез предлагать
А никто такое и не предлагает. Как я написал выше — это всего лишь пример, ни к чему не обязывающий. Как минимум эту задачу можно разбить на более читаемые и понятные.
У меня такой опыт мог бы сложиться, родись я хотя бы на пару лет пораньше. Нода появилась чуть раньше того момента, когда я нашёл первую работу по специальности) А вместе с ней пошли-поехали сборщики, фреймворки, пререндеринги и т.д.
Хотя с усами без ангуляров, реактов и вуёв я тоже экспериментировал, но исключительно на клиенте. Сейчас, конечно, всё это не особо актуально.
А сервера на C/C++ я вообще вживую ни разу не видел. Слышал только, что до появления PHP только на них и писали.
А так да, я понимаю, что были и раньше способы. Но сейчас они становятся «народными» и большее количество людей начинает их использовать.
Про телевизор понял, нагдлядно.
Ну как минимум тем, что фронтенд и бэкенд не пересекаются и гораздо более явно разделены. Никто не «натягивает вёрстку», не переписывает стили под CMS/фреймворки, не решает проблем с SEO и т.д. и т.п. Каждый занят своим делом: фронтендщик — пишет стили, разметку и интерактив, бэкендщик — создаёт бизнес-логику и API для неё. Изоморфность же достигается сама собой благодаря одному человеку, который один раз настроил сборку и сервер для SSR, а также разъяснил немногочисленные особенности разработки фронтендщикам. У меня этого достичь с одним лишь PHP на сервере не получалось :)
SSR != изоморфность, но SSR — инструмент, позволяющий достичь изоморфности.
Я просто хотел показать, что есть другая сторона, которая тоже имеет право на существование.
Идея с автопереключением SSR и SPA. Интересно, но оно того стоит? Можно просто рендерить на сервере всегда, так как это никому не приносит неудобств, кроме сервера. А если сервер начинает от этого уставать, то можно кешировать. Да и на самом деле мне кажется, что в перспективе SSR сравняется по производительности с обычными шаблонизаторами, ведь по сути задача его сводится к тому, чтобы получить данные и запихать их в разметку. А весь интерактив начинает свою работу уже на клиенте.
Про SSR — как ни крути, а это не то же самое, что мы делаем при построении старого доброго бэкенда с шаблонизаторами, jQuery и пр. Это всё равно развитие (= эволюция), то есть слияние всего того, что было хорошо в SPA с тем, что было хорошо в MPA. Плюс это развитие идеи пререндеринга просто потому, что SSR лучше пререндеринга почти во всём.
Про SEO — да, я признаю, что это субъективно. И да, SSR решает все проблемы разом, с этим я вообще не спорил.
Думаю, из контекста будет понятно, на что я отвечаю.
Статья конца 2013 года. Я не могу утверждать наверняка, потому что не имею такой статистики, но подозреваю, что ситуация сильно изменилась вместе с ростом качества, доступности и скорости интернета (много где появился 3G/4G, например), а так же падением популярности старых версий IE (УРА). Возможно, 0.2% людей с реально отключенным JS ещё остались, но цифра 0.9% скорее всего упала.
По поводу 3-секундного скрипта, кеша и доработок приложения — если применить код-сплиттинг и определённым образом настроить вебпак, то все эти проблемы решатся. Но, конечно, глупо спорить с тем, что SSR так или иначе повысит скорость отображения контента. Просто, опять же, я к тому, что это решаемо и без SSR.
Cordova и пр. — тут я просто, если честно, не понял, к чему была поднята тема. А так да, со всем согласен :)
Phantom/prerender решают те же проблемы, согласен. Но я считаю SSR своего рода эволюцией пререндеринга. Это более разумное решение, которое работает значительно быстрее + имеет хороший потенциал для оптимизации + с ним удобнее работать на сервере в целом (подключать какую-то аналитику, кешировать и прочее). То есть если есть равнозначный выбор между пререндерингом и SSR, то было бы глупо выбирать первое. Но для существующих проектов с большим количеством кода пререндеринг может быть единственным решением.
А SEO — да, главный аргумент лично для меня. Просто потому, что это единственный вариант писать код «без костылей» и не жертвовать SEO (ну, есть ещё пререндеринг, но свою позицию относительно него я уже описал). Но то, что он параллельно решает ряд других проблем или улучшает какие-то показатели — определённо, приятный бонус.
Опыт же крупных проектов по выпиливанию/впиливанию чего-то — думаю, не совсем об этом. Технологии в вебе, особенно на фронтенде, меняются с невероятной скоростью. С ними же растут потребности, критерии качества, размеры js/css файлов,… Появление проблем из-за этого всего неизбежно с любыми технологиями.
В каком плане не получают? Доклад посмотреть было бы интересно, да!
Я и не утверждал, что таких людей нет. Просто их недостаточно много для того, чтобы только ради них внедрять SSR. Конечно, всё будет зависеть от ЦА, но сложно представить такую ЦА, где достаточно большая доля людей без JS.
Нет, я серьёзно :) По двум причинам:
— скрипты грузятся один раз и кэшируются, то есть при всех последующих загрузках страницы проблем с этим не будет
— в SPA нет явных физических переходов между страницами сайта/приложения, поэтому потерпеть придётся всего один раз при открытии ресурса
Это легко решается с помощью code splitting в webpack. То есть я не утверждаю, что проблемы нет, но есть более простые альтернативные способы их решения. SSR же — стрельба из пушки по воробьям.
Ну для таких целей подозреваю (не уверен), что можно просто делать разные сборки одного и того же приложения. К тому же они будут существовать параллельно с SSR, так как они вообще не имеют прямого к нему отношения. Ну и JS эти технологии прекрасно исполняют (иначе зачем они вообще), так что это принципе не аргумент в данном случае.
Зачем же вы так меня обижаете :(
Я, наоборот, топлю за то, чтобы вообще любой проект сложнее бложика делать как SPA, а проблемы с SEO решать серверным рендерингом. При должной квалификации разработчиков в человекочасах потерь не будет (скорее наоборот), зато UI/UX получит значительный прирост.
Вообще, мой посыл не совсем в том, что не надо использовать SSR для чего-либо кроме SEO. Я говорю о том, что все остальные проблемы, которые решает SSR не стоят того, чтобы его внедрять, так как можно обойтись меньшей кровью.
Но с другой стороны SSR достаточно один раз настроить и потом везде использовать без дополнительных затрат, и все новые проекты лично я бы всегда делал с поддержкой SSR, так как мне, как разработчику, у которого есть для этого готовое решение, это ничего не стоит.
Другое дело пересаживать на SSR какой-то существующий фронтенд, тут всё значительно сложнее.
Environment agnostic — тоже не сказал бы. Всё равно для чтения HTML нужен браузер, который поддерживает также и JS, так что никаких дополнительных ограничений, связанных со средой выполнения, JS не накладывает. Я ни разу не встречал живого человека, который был бы одновременно в своём уме и выключал JS в браузере :)
Единственное, с чем глупо не согласиться — скорость первичной загрузки. Но это в случае с SPA мелочь, ради которой не стоит заморачиваться с SSR.
В общем, по моему мнению SEO — единственная причина использовать SSR. Я пытался придумать другие реально веские причины для этого, но так ни к чему и не пришёл.
Мало того, можно целые разделы рендерить исключительно на клиенте, типа тех же личных кабинетов со своими внутренними роутами (на Vue это делается очень просто). С сервера в таком случае приходит пустая страница или, скажем, какой-нибудь индикатор загрузки, а на клиенте уже получаем информацию о текущем пользователе (скажем, в хуке beforeMount или mounted, которые на сервере не вызываются) и выводим в зависимости от его наличия форму для входа или непосредственно личный кабинет (
<router-view />).В общем-то это всё, что нужно понимать, статья тут, мне кажется, не нужна :)
Но связи с серверным рендерингом по-прежнему не улавливаю :)
Неужели все, кто пытается реализовать SSR, не заметили, как, оказывается, всё элементарно?
Правда, этого всего и не должно быть в документации, так как её цель — описать возможности, а не давать готовый код. Второе как раз и есть задача, которую я пытаюсь решить в этой статье.
Но было бы правильно оставить в статье ссылку на документацию, это я сделаю в ближайшее время.
Я имел в виду, что брать пререндеринг при разработке нового SPA — это устаревший подход.
Есть ещё пререндеринг, но серверный рендеринг — это его эволюция, то есть пререндеринг просто можно считать устаревшим подходом.
Насчёт интерпретации js поисковиками я слышал, но я очень скептически к этому отношусь. Представьте, сколько мощностей нужно задействовать, чтобы за адекватное время запустить каждый
говносайт со всем его кодом в масштабах гугла. Ну и плюс слышал, что эта дрянь пока что не очень хорошо работает — старый добрый HTML всё равно надёжнее. По крайней мере ближайшие лет 5 точно (имхо).Ну а если даже такие усилия делать лень, то для каждой буквы есть соответствующий более длинный аналог: --watch, --resolve-url, --use, --out. И что же тут «плохо читается»?
1) Так кто мешает не подчеркивание использовать, а просто папку? Например, папка styles/main для основных файлов, все остальное в styles. Ну и как угодно по-другому. Да, скриптами сложно сделать именно как у вас, но зачем делать свалку файлов в одном месте, когда можно их распределить по смыслу без ущерба удобству?
2) Значит, в вашем случае такой подход, действительно, неприменим. Я не утверждал, что npm scripts полностью заменяет таск-менеджер — я говорил, что для простых (и наиболее распространенных) случаев он подходит больше.
3) Да, в таких случаях разумнее запускать отдельные js-файлы с реализацией задач через код, но что в этом плохого? Насколько я знаю, многие и с таск-менеджерами делают то же самое, вынося отдельные таски в отдельные файлы. Да и зачем задачи подгружать автоматом? Таски пишутся один раз и потом довольно редко изменяются, так что это не такая уж и проблема. Да и если это вдруг становится проблемой, то вы правильно заметили, что можно написать свой автолоадер для этого. И это совсем несложно.
4) Для человека, который не знает ни gulp, ни grunt (и т.п.), ни npm scripts совершенно нет никакой разницы. Но с тем, что модули таск-менеджеры популярнее, чем npm я согласен, так что в проекте, где все разрабы уже что-то знают, наверно, проще пользоваться модулем.
5) Стандартными — никак, но есть по крайней мере один модуль parallelshell (наверняка есть и другие, я не искал), задача которого как раз запускать в командной строке одновременно несколько процессов.
Таск-раннеры громоздки, их эффективность растет со сложностью задач, но их не стоит пихать всегда и везде. И агитирую я не переезжать на npm scripts, а воспринимать его как альтернативу.
А никто такое и не предлагает. Как я написал выше — это всего лишь пример, ни к чему не обязывающий. Как минимум эту задачу можно разбить на более читаемые и понятные.