Comments 44
Под кат, плиз.
UFO just landed and posted this here
Сделали генератор) github.com/tars/tars-cli
Как то я не очень понял, а от какой именно рутины TARS избавляет? От разового добавления нужных тасков в gulpfile? Вот если эта штуковина могла бы помогать создать кастомную структуру проекта и представить что-то типа GUI для настройки задач и установки любых модулей — было бы круто. А так — мне не очень понятен смысл. Может это просто какая-то специфичная БЭМерская проблема решается? Я не критикую, просто понять пытаюсь…
Например, особенно заметна помощь при избавлении от рутины при подготовке графики. Достаточно просто сохранить SVG-файл в нужной директории, использовать миксин и все, изображение уже на странице, со всеми минификациями, поддержкой любых экранов и поддержкой IE8, если необходимо.
Тоже касается и html, js, css. Все работает сразу из коробки. У меня есть сводная таблица с замерами времени верстки небольшого промо-сайта (7 страниц) без TARS (но с отдельными моментами, которые были автоматизированы) и с TARS. Разница оказалась ощутимой. Минимальный выигрыш был в работе с html — 2 часа (с 8 часов до 6), а максимальный — в работе с картинками. Там выигрыш составил 4 часа (с 6 часов до 2). По временным отрезкам можно примерно представить сложность проекта.
Вы можете многое менять в структуре проекта, используя опции и доп. таски. Создание любой кастомной структуры с автоматической поддержкой в тасках — это конечная цель.
По поводу GUI вопрос интересный, но крайне сложный. Есть подобные проекты с GUI (CodeKit, например). Но, признаюсь честно, пока совсем нет времени на создание хорошего, кроссплатформенного GUI. К тому же, я уверен, что с консолью так или иначе ладят все.
Про установку модулей, есть мысли о том, чтобы автоматизировать этот процесс, сделать шаблон модуля, от которого можно было бы реализовать что-то свое и легко устанавливать в TARS. Это мысли на ближайшее будущее.
В TARS нет никакой БЭМерской специфики. Каждый модуль можно использовать так, как захочется, я лишь в статье использовал БЭМ-терминологию. Просто разделение страницы на некие блоки/сущности/еще что-то — это просто хорошая практика, которая позволяет быстро разрабатывать и поддерживать проект. Вы сами вольны придумать назначение для модуля.
Надеюсь ответил на все вопросы и сомнения.
Тоже касается и html, js, css. Все работает сразу из коробки. У меня есть сводная таблица с замерами времени верстки небольшого промо-сайта (7 страниц) без TARS (но с отдельными моментами, которые были автоматизированы) и с TARS. Разница оказалась ощутимой. Минимальный выигрыш был в работе с html — 2 часа (с 8 часов до 6), а максимальный — в работе с картинками. Там выигрыш составил 4 часа (с 6 часов до 2). По временным отрезкам можно примерно представить сложность проекта.
Вы можете многое менять в структуре проекта, используя опции и доп. таски. Создание любой кастомной структуры с автоматической поддержкой в тасках — это конечная цель.
По поводу GUI вопрос интересный, но крайне сложный. Есть подобные проекты с GUI (CodeKit, например). Но, признаюсь честно, пока совсем нет времени на создание хорошего, кроссплатформенного GUI. К тому же, я уверен, что с консолью так или иначе ладят все.
Про установку модулей, есть мысли о том, чтобы автоматизировать этот процесс, сделать шаблон модуля, от которого можно было бы реализовать что-то свое и легко устанавливать в TARS. Это мысли на ближайшее будущее.
В TARS нет никакой БЭМерской специфики. Каждый модуль можно использовать так, как захочется, я лишь в статье использовал БЭМ-терминологию. Просто разделение страницы на некие блоки/сущности/еще что-то — это просто хорошая практика, которая позволяет быстро разрабатывать и поддерживать проект. Вы сами вольны придумать назначение для модуля.
Надеюсь ответил на все вопросы и сомнения.
Нет, я все еще не понял. Окружение проекта со всеми вотчерами, конкатами, минификаторами, оптимизаторами, автопрефиксами и прочим — настраивается один раз, и затем все это можно многократно переиспользовать. Можно взять готовое с помощью одного из Yeoman-овских генераторов, если уж совсем не заморачиваться. И это задача не на 4 часа. Тонкая настройка может быть перманентным процессом, но она также не отнимает много времени. При использовании модных веб-компонентов и Polymer-овского vulcanize, работа с шаблонами и html в целом — довольно приятное занятие. И я не понял с каким воркфлоу идет сравнение по времени, работы с картинками например, с оптимизацией вручную в фотошопе?
Мое решение предоставляет готовый сборщик, из которого каждый может использовать то, что нравится. Поверьте, далеко не все хотят заниматься настройкой окружения, сборщика и т.д. Есть те, кому нужно уже готовое решение.
Отлично, если вы можете легко для себя настроить окружение так, как вам удобно. Возможно для вас нет смысла использовать TARS полностью, а стоит выдрать только отдельные таски или вообще его не использовать)
Отлично, если вы можете легко для себя настроить окружение так, как вам удобно. Возможно для вас нет смысла использовать TARS полностью, а стоит выдрать только отдельные таски или вообще его не использовать)
Сделали генератор, теперь, думаю польза стала более явная) github.com/tars/tars-cli
рандомный hash
А чего не основанный на содержимом? Я вот беру конкатенированное содержимое, md5 от него и потом первые пять символов от полученного хэша. Использую в другом контексте, у меня движок сам всю эту рутину делает, но суть понятна, если вы обновляете один CSS файл и пересобираете проект — нет смысла менять все хэши, ибо пользователю придется всё это потом грузить заново, а так только изменившуюся часть.
Вот ещё, в коде для IE8 отличается только background-image, а генерируется весь блок, тоже как-то не оптимально получается.
На самом деле не только им. SVG-спрайт, в который собираются все SVG-изображения, может отличаться по компановке от спрайта растрированых SVG для IE8, значит уже как минимум два свойства различны. Возможно имеет смысл переиспользовать вычисленные размеры SVG-изображения для растрового, но подсчет размеров для растровых картинок не занимает много времени.
Но на самом деле — это вообще не важно, так как для IE8 будет отдельный файл, в котором не будет стилей для подключения SVG, а в стилях для современных браузеров не будет стилей для IE8. На скрине они вместе лишь для наглядности.
Но на самом деле — это вообще не важно, так как для IE8 будет отдельный файл, в котором не будет стилей для подключения SVG, а в стилях для современных браузеров не будет стилей для IE8. На скрине они вместе лишь для наглядности.
Ошибся комментарием.
Это ответ на предыдущий: «Отличная мысль, добро пожаловать в issue) Всегда рад хорошим идеям»
Это ответ на предыдущий: «Отличная мысль, добро пожаловать в issue) Всегда рад хорошим идеям»
Артём,
— «сборщик html-вёрстки», может быть «сборщик html-разметки» или «сборщик вёрстки»;
— поправь свой БЭМ, плиз, menu, menu__item, menu__list, menu__link / menu__itemLink
А в целом, молодец (ы) :)
— «сборщик html-вёрстки», может быть «сборщик html-разметки» или «сборщик вёрстки»;
— поправь свой БЭМ, плиз, menu, menu__item, menu__list, menu__link / menu__itemLink
Заголовок спойлера
<nav class=”menu”>
<ul class=”menu__list”>
<li class=”menu__listItem”>
<a href=”url” class=”menu__listItemLink”>title</a>
</li>
...
</ul>
</nav>
А в целом, молодец (ы) :)
Чем больше смотрю подобные сборщики, тем больше понимаю, что все таки под нужды компании нужно писать свои таски. Мы над своим работаем и улучшаем почти что из проекта в проект. А для продуктовых компаний так вообще писать «для себя» просто необходимость.
Но всё равно спасибо за ваше видение роли сборщика фронтенда.
Но всё равно спасибо за ваше видение роли сборщика фронтенда.
Устаревшие у вас инструменты для CSS. Нет ни одного плагина PostCSS, даже хотя бы Автопрефиксера (Google рекомендует только его для работы с префиксами).
Мне кажется TARS и подобные инструменты очень специфичны. Да, вы сделали возможность всё менять, добавлять своё и кастомизировать как угодно, но опять же придётся разбираться не только с Gulp, а теперь ещё и с TARS, пусть это и всего лишь добавить 10-20 минут на каждую задачу вначале.
На мой взгляд, в каждой компании есть уже свой конвейер, который не сильно меняется от проекта к проекту и намного проще что-то изменить в нём. Да и строить сборщик на основе другого сборщика, который обретёт в будущем ещё один сборщик… какая-то абстракция на абстракции.
И тем не менее, работа проделана большая и думаю TARS найдёт своих пользователей :)
На мой взгляд, в каждой компании есть уже свой конвейер, который не сильно меняется от проекта к проекту и намного проще что-то изменить в нём. Да и строить сборщик на основе другого сборщика, который обретёт в будущем ещё один сборщик… какая-то абстракция на абстракции.
И тем не менее, работа проделана большая и думаю TARS найдёт своих пользователей :)
Как раз сегодня ночью организовывал свои gulp task'и для React 13 + babel.
Приятно что вы заботитесь а кастомизации, но все-таки мне кажется что build система должна быть жестко разделена от продукта config файлом, и навязывать разработчику где ему хранить шаблоны, и как разбивать код на модули — очень не благородное дело. В случае с React здесь появляются различные конфликты например.
А так, спасибо)
Приятно что вы заботитесь а кастомизации, но все-таки мне кажется что build система должна быть жестко разделена от продукта config файлом, и навязывать разработчику где ему хранить шаблоны, и как разбивать код на модули — очень не благородное дело. В случае с React здесь появляются различные конфликты например.
А так, спасибо)
Gulp просто чудесен и разобраться в нем достаточно просто. Ничуть не оспариваю ваш труд (весьма полезный), но он скорее представляет академический интерес, так как все равно кто-то запилит таски для dev/stage/production с тестами и поэтессами.
Например я уже пишу на ES6 потому что это удобно и есть gulp-babel, а у вас его и bower все еще нет. Также не нашел упоминания base64 (есть плюсы и минусы, но до 32кб спрайтами устраивает).
И неплохо было бы добавить gulp-notify.
Например я уже пишу на ES6 потому что это удобно и есть gulp-babel, а у вас его и bower все еще нет. Также не нашел упоминания base64 (есть плюсы и минусы, но до 32кб спрайтами устраивает).
И неплохо было бы добавить gulp-notify.
1) ES6 – это круто. И да, плохо, что сразу это не внедрил. А вот с bower все сложнее. В нем могут быть пакеты с html, css и js, а у сборщика есть некая файловая структура, по которой все нужно разложить. Поэтому внедрение bower – задача сложная.
2) base64 – это медленно (render и paint). Я сам проводил исследования + есть ряд статей на эту тему (например, calendar.perfplanet.com/2014/tips-for-optimising-svg-delivery-for-the-web/) Я рекомендую отказаться все же от base64, так как на мобильных устройствах это медленнее на порядок, чем спрайт.
3) gulp-notify есть + есть сахар для его легкого использования в тасках.
Вообще, я уже писал выше, не все хотят заниматься настройкой окружения под себя + какие-то вещи из TARS вы может использовать отдельно, так как каждый такс TARS – обычный gulp-таск.
2) base64 – это медленно (render и paint). Я сам проводил исследования + есть ряд статей на эту тему (например, calendar.perfplanet.com/2014/tips-for-optimising-svg-delivery-for-the-web/) Я рекомендую отказаться все же от base64, так как на мобильных устройствах это медленнее на порядок, чем спрайт.
3) gulp-notify есть + есть сахар для его легкого использования в тасках.
Вообще, я уже писал выше, не все хотят заниматься настройкой окружения под себя + какие-то вещи из TARS вы может использовать отдельно, так как каждый такс TARS – обычный gulp-таск.
Можно взять www.npmjs.com/package/gulp-bower, www.npmjs.com/package/gulp-bower-files или же сконфигить директорию через .bowerrc
UFO just landed and posted this here
В TARS мне не нравится:
Ранее использовал gulp-starter от Vigetlabs, когда он еще на browserify был (теперь на webpack). Потом перешел на wepack + минимум gulp.
Как ни крутите, но гапловскими задачками вы вряд ли соберете фронтенд качественнее, чем webpack'ом. Также хочу предостеречь от browserify. С одной стороны, освоить его проще, но с другой — он ограниченный, бажный и потихоньку затухает.
- отсутствие модульности (я говорю commonjs)
- отсутствие тестирования
- громоздкий
Ранее использовал gulp-starter от Vigetlabs, когда он еще на browserify был (теперь на webpack). Потом перешел на wepack + минимум gulp.
Как ни крутите, но гапловскими задачками вы вряд ли соберете фронтенд качественнее, чем webpack'ом. Также хочу предостеречь от browserify. С одной стороны, освоить его проще, но с другой — он ограниченный, бажный и потихоньку затухает.
Также в TARS неполностью реализован cache-busting: файлы шрифтов в стилях остаются без хеша.
1) webpack уже почти в тестировании. 1.7.0 будет максимуму в начале той недельки;
2) если речь идет о тестировании самого TARS, то это не так, сам TARS тестируется. Если речь о том, что workflow нет для тестирования проекта — это да. Задача есть, было бы неплохо, если бы кто-то помог с этим;
3) Объясните, что это значит, пожалуйста.
Про webpack я уже ответил. И тут вопрос не про качество, а про скорость сборки скорее.
По поводу кеширования шрифтов: а зачем хеш для них нужен? Есть вероятность, что вы сделаете другой шрифт под тем же именем? У них внутри в любом случае свое имя зашито и ОС понимает, с каким шрифтом имеет дело исходя не только из названия шрифта. В общем про этот момент не понятно.
2) если речь идет о тестировании самого TARS, то это не так, сам TARS тестируется. Если речь о том, что workflow нет для тестирования проекта — это да. Задача есть, было бы неплохо, если бы кто-то помог с этим;
3) Объясните, что это значит, пожалуйста.
Про webpack я уже ответил. И тут вопрос не про качество, а про скорость сборки скорее.
По поводу кеширования шрифтов: а зачем хеш для них нужен? Есть вероятность, что вы сделаете другой шрифт под тем же именем? У них внутри в любом случае свое имя зашито и ОС понимает, с каким шрифтом имеет дело исходя не только из названия шрифта. В общем про этот момент не понятно.
По поводу кеширования шрифтов: а зачем хеш для них нужен?
Иконочные шрифты периодически обновляются, например, materialdesignicons или font-awesome, которые устаналиваются через bower или npm. Иногда в них меняются коды иконок. И если cache-busting применяется только к стилям, то клиент вместо "галочки" видит "крестик", вместо "котика" — "собачку" и т.п.
К тому же, кроме шрифтов, вы не применяете cache-busting к картинкам background-image.
Согласен. Кажется я знаю, как это можно решить, добавлять хеш в имя папки со статикой, тогда не придется врсионировать каждый файл отдельно. Как вам идея?
Мне не нравится идея изменять названия папок и файлов. На то есть причины:
Куда лучше добавлять хеш в query string.
- нельзя простым способом задеплоить ASP.NET проект, потому что невозможно добавить в проект файлы собранного фронтенда (пути к этим файлам меняются). Также получаем сложности с роутингом.
- если меняются названия файлов, то отладчик в браузере будет закрывать старые версии этих файлов, будут теряться брейкпоинты, маппинг на файловую систему, позиция курсора.
Куда лучше добавлять хеш в query string.
И главный вопрос: при обновлении одного шрифта браузеру придется обновить всю статику?
Погодите, хеш добавляется только при релизе. В разработке никакого хеша нет.
Я говорю о браузере конечного пользователя.
Во-первых, насколько часто у вас релизы происходят? Во-вторых, в чем проблема подгрузить новые ресурсы при первом входе?
1. Суммарный пожатый фрондент весит 3.2 МБ. Релизы происходят по-разному: бывает раз в неделю, бывает раз в день.
2. Regular 3G 750 Кб/с грузит всю статику за 22 сек. Загрузка сопровождается прогресс-баром.
3. Зачем перегружать весь фронтенд, когда нужно обновить только часть? Только потому что TARS не может иначе?
2. Regular 3G 750 Кб/с грузит всю статику за 22 сек. Загрузка сопровождается прогресс-баром.
3. Зачем перегружать весь фронтенд, когда нужно обновить только часть? Только потому что TARS не может иначе?
TARS по умолчанию создает 1 хеш на все. С новым релизом хеш поменяется, это да. Никто не мешает этот механизм настроить так, как вам будет удобно.
Скажите, часто ли такое бывает, что вы правите только стили и релизите это? Скорее всего правится еще и JS, и шаблоны. Хотя вот щаблоны могут и не меняться. Часто ли вы меняете только шрифт и релизите?
Скажите, часто ли такое бывает, что вы правите только стили и релизите это? Скорее всего правится еще и JS, и шаблоны. Хотя вот щаблоны могут и не меняться. Часто ли вы меняете только шрифт и релизите?
А про громоздкость так и не ответили.
Sign up to leave a comment.
TARS, сделай уровень frontend-рутины 0%