Comments 18
Неплохо, но надо еще подумать над этим
Выглядит интересно и разумно, но мне кажется не взлетит. Не зря ведь инвалидацию кеша называют одной из сложнейших задач в программировании. Да и просто сваливать главную фичу кеширование на авторов плагинов не разумно — не думаю, что народ будет запариваться на написание плагинов. Тот же gulp вполне не плохо со своей задачей справляется пусть у него и подход 1:1.
Система сборки не должна заниматься компилированием ресурсов. Компиляция должна лежать на уровне ниже — чтение файлов. Таким образом, изменив `menu.css` на `menu.less`, или `collapser.js` на `collapser.es6` — это не должно затрагивать систему сборки — всё должно оставаться как есть и работать сразу. И такой подход нас «бесплатно» избавляет от длительных компиляций при `лайфрелоуде`.
А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки. Стили, скрипты и шаблоны подгружаются в не собранном виде. То есть, ресурсы подгружаются отдельно и только те которые нужны в данный момент. Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
А система сборки применяется единожды перед деплоем.
А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки. Стили, скрипты и шаблоны подгружаются в не собранном виде. То есть, ресурсы подгружаются отдельно и только те которые нужны в данный момент. Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
А система сборки применяется единожды перед деплоем.
А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки
В таком случае, объясните мне пожалуйста, как вы будете собирать SASS, Haml?
Как вы считаете, оптимальнее каждый раз в режиме реального времени заново собирать все coffee файлы? Аналогичную задачу может решить инкрементальная сборка: ставите вотчер на coffee, после первой сборки он кеширует сохраненное состояние, а при сл. операции над каким-либо файлом, он выполнит сборку только для него. На моей, не особо мощной машине, это занимает 200 ms, а настройка решения занимает 5 минут, если разворачивать систему сборки с нуля. Аналогичное решение для компиляции coffee в js с последующим выполнением, я, признаться, не видел, и с трудом могу себе представить: в какой момент вы будете запускать компиляцию? Как вы будете избегать компиляции неизмененных файлов? Если вы в dev режиме не минифицируете файлы, то каким образом вы скомпилируете все файлы? Если же вы хотите компилировать не все файлы, а только по мере их использования, как вы это собираетесь делать? Приведите, пожалуйста, любой, пускай даже самый простой пример того, как это будет выглядеть. Предположим, у нас есть модуль А и модуль Б, они написаны на coffee. И есть точка входа в проект — index.html, из которой должен быть вызван модуль А, который зависит от модуля Б. Какое решение для «компиляции на лету» вы бы предложили? (я не стараюсь катить бочку, поймите правильно, я просто не вижу рационального пути решения этой задачи без системы сборки, или, как минимум, таск раннера а-ля Grunt).
Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
В чём состоит упрощение? В Chrome Dev Tools уже давно есть поддержка source maps, но, прошу заметить, я нигде не говорил, что при инкриментальной сборке проекта в dev режиме, вам требуется минифицировать файлы.
Я также за рациональный путь) А всё очень просто — HttpHandlers или file reader hooks. Это вводит дополнительную абстракцию в систему чтения/запроса файлов. Понимаете системе сборки или браузеру абсолютно не важно, что в файле coffeescript, при чтении файла он автоматически превращается в javascript — эдакий file middleware. Также и со стилями, в файле less, а при чтении получаем `css`. Вот и получается, что о компиляции нам больше нигде не нужно беспокоится, и о ней можно забыть — это всего лишь файл, обычный javascript. Вот теперь как быть с этим javascript, где и как его собирать, какую модульную систему использовать — вот что важно. А здесь много разных вариантов — мы используем свое решение, в дев моде каждый файл загружает свои зависимости сам, через обычный
<script src="/file.es6"></script> (с source maps конечно). А для релиза все собираем. Много чего ещё есть, на этом собаку сьели, так что, если есть другие рациональные вопросы, буду рад ответить.Если я не ошибаюсь, то HttpHandlers — это ASP.NET решение, а веб-разработка, как вы понимаете, крутится не только вокруг него. Тем более, судя по всему, вы выполняете ту же задачу, которую выполняет система сборки, только делаете это своим велосипедом способом. И, я по-прежнему не понимаю, как вы будете компилировать SASS(а не less) и Haml.
Нет, я о httphandler как о обработчике запроса в общем, браузер запрашивает 'menu.sass', а запрос обрабатывает не static handler, а обработчик который предварительно компилирует ресурс. Такое реализуется на любом бэкенде, и asp.net здесь не причем. И для большинства уже все есть, ничего самому делать не нужно.
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa? Препроцессор есть как для первого так и для второго.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa? Препроцессор есть как для первого так и для второго.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa
У меня были сомнения, что вы собираетесь компилировать LESS на фронте.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
Почему же? Я выступаю за систему сборки, которая имеет, к примеру, 3 задачи: собрать dev, собрать production, повесить вотчер для инкрементальной сборки(для dev). Когда вы запускаете dev билд, у вас выполняется стандартный набор действий: А, Б, В. Когда вы запускаете production билд, у вас запускается dev билд(А, Б, В), а потом запускается еще Г, Д, Е. Если же запускать инкрементальную сборку, то мы видим следующее: в системе висит демон, который отслеживает изменения для опр. формата файлов в директориях проекта, и при каждом изменении файла, он собирает его, используя его зависимости и кладет в результирующую директорию.
На самом деле, мы говорим не о таких разных вещах. Просто, насколько я понимаю, у вас есть одно решение для dev сборок(на уровне обработок запроса пользователя) и другое решение для production сборок. Я же просто сторонник того, что любую сборку должен выполнять один и тот же инструмент, просто по разным сценариям. В этом есть и другой плюс: т.к. мы рассматриваем инструменты для frontend разработчика, то будет справедливо сказать, что большая часть javascript программистов не знают серверных ЯП, и/или не знакомы с настройкой nginx/apache, а это значит, что путь сборки, подобный тому, что вы предложили, будет на порядок сложнее, т.к. он требует доп. знаний, но очевидных преимуществ не несет: нам все равно нужна система для сборки production, верно?
Понимаете, у меня в деве никаких тасков `а, б, в` нету. Открыл браузер, редактор и вперед. А так как у нас ещё к тому же компонентная архитектура приложений, то поддерживается лайфрелоуд не только стилей, но и js кода. Быстрый пример:
Но здесь я не хочу вас переубеждать, что и как лучше — если вам удобнее так как вы описываете, то я только рад. Но для себя я определился и другим также советую — настраивать систему разработки так, что бы компиляция происходила на самом нижнем уровне — при чтении файла. Таким образом, будет казаться, что браузер поддерживают coffescript например `нативно`. (_подключил файл через `script` тэг и он работает_). И тогда останется выбрать лишь модульную систему которая загружает скрипты/стили. Для которой определённо уже имеется свой `builder`. А код может быть написан, хоть частично на typescript, частично на coffee, a остаток на es6 — все равно каждый файл в результате при чтении становится js, или css, или…. И это жуть как удобно )
Youtube
Но здесь я не хочу вас переубеждать, что и как лучше — если вам удобнее так как вы описываете, то я только рад. Но для себя я определился и другим также советую — настраивать систему разработки так, что бы компиляция происходила на самом нижнем уровне — при чтении файла. Таким образом, будет казаться, что браузер поддерживают coffescript например `нативно`. (_подключил файл через `script` тэг и он работает_). И тогда останется выбрать лишь модульную систему которая загружает скрипты/стили. Для которой определённо уже имеется свой `builder`. А код может быть написан, хоть частично на typescript, частично на coffee, a остаток на es6 — все равно каждый файл в результате при чтении становится js, или css, или…. И это жуть как удобно )
Понимаете, я совершенно не против вашего подхода. Я абсолютно уверен, что в рамках вашего проекта это решение прекрасно работает. Дело лишь в том, что на мой взгляд, нельзя сказать, что для всех систем ваше решение является оптимальным, а сказанные вами слова
В конце концов, мы здесь обсуждаем систему сборки Broccoli, а не разницу в подходах ;)
Я бы с удовольствием перенес наше общение в лс, чтобы оставить в этой ветке только сообщения, относящиеся к теме.
Система сборки не должна заниматься компилированием ресурсовили
в dev моде вообще не должно быть никаких процессов сборкиявляются слишком громкими.
В конце концов, мы здесь обсуждаем систему сборки Broccoli, а не разницу в подходах ;)
Я бы с удовольствием перенес наше общение в лс, чтобы оставить в этой ветке только сообщения, относящиеся к теме.
Полностью вас поддерживаю, что сборка должна быть лишь перед деплоем.
В соседнем посте я писал о basis.js. Так вот в dev все разобрано, тоже есть live update (только js не обновляем, это нельзя сделать безопасно). Перед деплоем все это собирается. По принципу «граф на входе, граф на выходе», которые отстраиваются самостоятельно, по переданному индексному html файлу.
Я думаю, будущее именно за такими системами разработки и сборки.
В соседнем посте я писал о basis.js. Так вот в dev все разобрано, тоже есть live update (только js не обновляем, это нельзя сделать безопасно). Перед деплоем все это собирается. По принципу «граф на входе, граф на выходе», которые отстраиваются самостоятельно, по переданному индексному html файлу.
Я думаю, будущее именно за такими системами разработки и сборки.
в PhpStorm добавили поддержку Grunt из коробки в EAP версии. Это конечно не самый правильный подход, реализовывать все функции связанные со сборкой проекта в IDE, но все-таки есть некая сермяжная правда в этом.
Установил IDE и начал работать, хотя для сборки Sass все равно исползуется внешний ruby движок
Установил IDE и начал работать, хотя для сборки Sass все равно исползуется внешний ruby движок
Почему-то с mincer нет сравнения. Может кто-нибудь поделиться опытом?
UFO just landed and posted this here
Sign up to leave a comment.
Broccoli: первый бета-релиз