Разбираемся в DevOps и Js на примере Dillinger.io

[@madmages]

сложилось впечатление что этот редактор построен на технологиях ради технологий.

[@EliseeAlex]

Согласен, но в этом есть смысл. Скорее всего, эти технологии пришли из сложных проектов, где появились не просто так. А на таких простых проектах можно в них разобраться.

[@zxcabs]

Простите но:

Или на русском: мы сообщаем Gulp за какими файлами нужно следить. Если кто-то из них обновился, то при помощи Webpack он соберёт скрипт из зависимостей и кусочков Js-кода и превратит Sass в Css. Дальше, он попросит браузер обновить страницу при помощи browserSync.

зачем этот костыль? Вебпак все это делает сам в том числе и сообщит клиенту какой модуль обновился и пришлет новый модуль, дальше останется только обработать это событие.

[@EliseeAlex]

Я думаю, что это не костыль, а попытка не смешивать мух с котлетами. Задача Webpack — объединять файлы и резолвить зависимости. Он может сообщать, что файл обновился, обновлять браузер, превращать Sass в Css и минифицировать его, но описание процесса сборки приложения — не его основная задача.

С другой стороны в Task Runner'ах (Gulp, Grunt и т.д.) основная возможность — описание процесса сборки проектов. В Gulp используют идеи Stream'ов, это значит, что можно задать процесс сборки приложения в таком виде: для всех файлов *.sass нужно применить такие-то плагины, если в процессе произошла ошибка нужно что-то залогировать (или к примеру откатиться до предыдущей версии), дальше нужно сохранить файл с расширением css в такую-то папку и обновить браузер. Так же можно писать операторы ветвления, то есть разделять на Production и Developer режим (или не собирать приложения после 3 часов ночи и говорить, что пора спать). В таком жизненном цикле Wepback — просто ещё одна утилита, учавствующая в процессе сборки.

Конечно, можно для всего этого использовать Webpack и это отличный подход для проектов с простым процессом сборки. Но использовать Webpack для сложного процесса сборки, включающего разлив на сервера, запуск тестов, статический анализ кода и другие плюшки, куда больший костыль.

[@zxcabs]

Это костыль, хотя бы потому что вебпак при запуске в `watch` загружает все дерево в память и следит за изменением файлов и только теми которые реально используются в проекте и при их изменении он осуществляет сборку сразу а не начинает пересобирать все с нуля, как это сделано в вашем случае.

Про деплой и тесты это вы уже сами додумали, я ничего подобного не писал.