Честно говоря, не понимаю проблемы размера css-файла при использовании примесей. Ведь gzip все это великолепно сожмет же? А большое количество @extend, как верно заметил vdv73rus, может привести к багам в итоге.
Подскажите, а в чем приватность метода, если я все же могу получить значение, используя symbol. Или я чего-то не понял?
Попадёт ли свойство, объявленное через symbol к ребёнку при наследовании?
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-таск.
Была мысль вынести паттерны путей до разных файлов сборщика в конфиг, но конфиг получился большим слишком, что стало страшно) Как считаете, было бы удобнее, если бы структуру описать можно было бы в виде этого одного конфига? Не пугались бы люди?)
Естественно, всем не угодишь. Поэтому добавлены пользовательские таски.
На самом деле, можно выкинуть все таски и заюзать систему хранения тасков отдельно. Были мысли вынести это отдельно, только вот не знал, будет ли кто-то это использовать в таком виде.
Мое решение предоставляет готовый сборщик, из которого каждый может использовать то, что нравится. Поверьте, далеко не все хотят заниматься настройкой окружения, сборщика и т.д. Есть те, кому нужно уже готовое решение.
Отлично, если вы можете легко для себя настроить окружение так, как вам удобно. Возможно для вас нет смысла использовать TARS полностью, а стоит выдрать только отдельные таски или вообще его не использовать)
На самом деле не только им. SVG-спрайт, в который собираются все SVG-изображения, может отличаться по компановке от спрайта растрированых SVG для IE8, значит уже как минимум два свойства различны. Возможно имеет смысл переиспользовать вычисленные размеры SVG-изображения для растрового, но подсчет размеров для растровых картинок не занимает много времени.
Но на самом деле — это вообще не важно, так как для IE8 будет отдельный файл, в котором не будет стилей для подключения SVG, а в стилях для современных браузеров не будет стилей для IE8. На скрине они вместе лишь для наглядности.
Например, особенно заметна помощь при избавлении от рутины при подготовке графики. Достаточно просто сохранить SVG-файл в нужной директории, использовать миксин и все, изображение уже на странице, со всеми минификациями, поддержкой любых экранов и поддержкой IE8, если необходимо.
Тоже касается и html, js, css. Все работает сразу из коробки. У меня есть сводная таблица с замерами времени верстки небольшого промо-сайта (7 страниц) без TARS (но с отдельными моментами, которые были автоматизированы) и с TARS. Разница оказалась ощутимой. Минимальный выигрыш был в работе с html — 2 часа (с 8 часов до 6), а максимальный — в работе с картинками. Там выигрыш составил 4 часа (с 6 часов до 2). По временным отрезкам можно примерно представить сложность проекта.
Вы можете многое менять в структуре проекта, используя опции и доп. таски. Создание любой кастомной структуры с автоматической поддержкой в тасках — это конечная цель.
По поводу GUI вопрос интересный, но крайне сложный. Есть подобные проекты с GUI (CodeKit, например). Но, признаюсь честно, пока совсем нет времени на создание хорошего, кроссплатформенного GUI. К тому же, я уверен, что с консолью так или иначе ладят все.
Про установку модулей, есть мысли о том, чтобы автоматизировать этот процесс, сделать шаблон модуля, от которого можно было бы реализовать что-то свое и легко устанавливать в TARS. Это мысли на ближайшее будущее.
В TARS нет никакой БЭМерской специфики. Каждый модуль можно использовать так, как захочется, я лишь в статье использовал БЭМ-терминологию. Просто разделение страницы на некие блоки/сущности/еще что-то — это просто хорошая практика, которая позволяет быстро разрабатывать и поддерживать проект. Вы сами вольны придумать назначение для модуля.
Надеюсь ответил на все вопросы и сомнения.
Предположим, у меня есть Parent с символом role. Далее я делаю Child, который наследует свойства Parent. Будет ли доступ в Child к role у Parent?
Попадёт ли свойство, объявленное через symbol к ребёнку при наследовании?
2) base64 – это медленно (render и paint). Я сам проводил исследования + есть ряд статей на эту тему (например, calendar.perfplanet.com/2014/tips-for-optimising-svg-delivery-for-the-web/) Я рекомендую отказаться все же от base64, так как на мобильных устройствах это медленнее на порядок, чем спрайт.
3) gulp-notify есть + есть сахар для его легкого использования в тасках.
Вообще, я уже писал выше, не все хотят заниматься настройкой окружения под себя + какие-то вещи из TARS вы может использовать отдельно, так как каждый такс TARS – обычный gulp-таск.
На самом деле, можно выкинуть все таски и заюзать систему хранения тасков отдельно. Были мысли вынести это отдельно, только вот не знал, будет ли кто-то это использовать в таком виде.
Отлично, если вы можете легко для себя настроить окружение так, как вам удобно. Возможно для вас нет смысла использовать TARS полностью, а стоит выдрать только отдельные таски или вообще его не использовать)
У каждого БЭМ свой) Это так, для примера лишь.
Главное, чтобы это на пользу было)
Но на самом деле — это вообще не важно, так как для IE8 будет отдельный файл, в котором не будет стилей для подключения SVG, а в стилях для современных браузеров не будет стилей для IE8. На скрине они вместе лишь для наглядности.
Это ответ на предыдущий: «Отличная мысль, добро пожаловать в issue) Всегда рад хорошим идеям»
Тоже касается и html, js, css. Все работает сразу из коробки. У меня есть сводная таблица с замерами времени верстки небольшого промо-сайта (7 страниц) без TARS (но с отдельными моментами, которые были автоматизированы) и с TARS. Разница оказалась ощутимой. Минимальный выигрыш был в работе с html — 2 часа (с 8 часов до 6), а максимальный — в работе с картинками. Там выигрыш составил 4 часа (с 6 часов до 2). По временным отрезкам можно примерно представить сложность проекта.
Вы можете многое менять в структуре проекта, используя опции и доп. таски. Создание любой кастомной структуры с автоматической поддержкой в тасках — это конечная цель.
По поводу GUI вопрос интересный, но крайне сложный. Есть подобные проекты с GUI (CodeKit, например). Но, признаюсь честно, пока совсем нет времени на создание хорошего, кроссплатформенного GUI. К тому же, я уверен, что с консолью так или иначе ладят все.
Про установку модулей, есть мысли о том, чтобы автоматизировать этот процесс, сделать шаблон модуля, от которого можно было бы реализовать что-то свое и легко устанавливать в TARS. Это мысли на ближайшее будущее.
В TARS нет никакой БЭМерской специфики. Каждый модуль можно использовать так, как захочется, я лишь в статье использовал БЭМ-терминологию. Просто разделение страницы на некие блоки/сущности/еще что-то — это просто хорошая практика, которая позволяет быстро разрабатывать и поддерживать проект. Вы сами вольны придумать назначение для модуля.
Надеюсь ответил на все вопросы и сомнения.