TARS, сделай уровень frontend-рутины 0%

    image

    Frontend с каждым днём становится сложнее. Задачи — объёмнее, пользовательский интерфейс — насыщеннее, HTML, CSS и Javascript — огромнее, а сон фронтендера — короче и беспокойнее. Необходимо грамотно структурировать код, выполнять множество рутинных задач (компиляция css- и js-препроцессоров, сборка спрайтов, подготовка и оптимизация изображений, минификация файлов и др). Если вы работаете в команде — это автоматически увеличивает сложность разработки. Чтобы решить эти проблемы, я создал TARS — сборщик html-вёрстки, основанный на gulpjs.

    Мы в 2ГИС знаем о frontend-рутине не понаслышке. В компании создаётся много веб-проектов различной сложности: от порталов и онлайн-карты, до различных лэндингов и промо-сайтов. Мы устали от скучного копипаста при работе с html, подготовки графики для дисплеев с высокой плотностью пикселей, минификации всего, что только можно минифицировать и т.д. Казалось, что все эти вещи машина может спокойно сделать за нас. Поэтому я решил разработать инструмент для автоматизации львиной доли frontend-рутины.

    UPD: мы выпустили много новинок в TARS и даже написали об этом статью!

    Что хотелось получить от этого инструмента:
    • автоматизировать всё, что можно;
    • использовать уже существующие наработки, а значит использовать знакомый нам язык программирования — JavaScript, знакомую экосистему — Node.js и npm;
    • базовый набор функций в одном инструменте;
    • удобное API;
    • кроссплатформенность.

    Прежде чем писать своё, сначала мы с коллегами поискали уже готовые решения. Нашлось их очень много. Вот выжимка, как мне кажется, наиболее интересных проектов:

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

    Тогда родился TARS, который вобрал всё лучшее из уже готовых проектов.

    TARS — это набор gulp-тасков для автоматизации большинства задач frontend’а + возможность лёгкого добавления новых, если будет чего-то не хватать. TARS можно назвать фреймворком для gulp. Подходит как отдельным разработчикам, так и большим командам. С TARS легко разрабатывать проекты любой сложности: от лендинга до огромного портала. Вам даже не нужно знать, как работает gulp, так как всё, что можно, было вынесено в опции, весь код и варианты использования задокументированы.

    Ключевые особенности у TARS.
    1. Jade или Handlebars в качестве html-шаблонизатора или обычный html (при выборе Handlebars).
    2. SCSS, Less, Stylus в качестве css-препроцессора или ламповый CSS (поддерживается синтаксис в рамках любого из препроцессоров). Недавно появился проект fmp, в котором это тоже доступно.
    3. Возможность отделить данные от представления, передав данные в виде js-объекта в шаблоны. Так мы используем один и тот же шаблон много раз, но с разными данными, без копипаста, библиотек и фреймворков. Подробнее об этом будет рассказано ниже.
    4. Вотчер chokidar.
    5. По-настоящему умная работа с изображениями. Максимально упрощается разработка под экраны с высокой плотностью пикселей. Об этом будет рассказано ниже.
    6. Легко расширять своими тасками. Модульная структура.
    7. Отличная документация.
    8. Создание архива готовой сборки. Мелочь, а приятно.

    Ну и, конечно же, конкатенации, минификации и оптимизации всего, что только можно, несколько режимов сборки и т.д.

    У TARS внушительный набор опций, каждая из которых подробно описана в документации.

    Мы уже использовали TARS в разработке сайта о технологиях, продуктах и дизайне
    2ГИС, различных лендингов (Промо приложения 2ГИС для Windows Phone, франшиза 2ГИС для Казахстана, сайт внутренней конференции разработчиков 2ГИС), сайта 5pm и др.

    Как всё работает


    Вам понадобятся:
    • Node.js (возможно, скоро и на IO.js, работаем над этим);
    • Gulp, установленный глобально;
    • Архив с TARS.

    После того, как мы скачали архив, выполняем команду gulp init. Она подключит выбранные html-шаблонизатор и css-препроцессор (указываются в конфиге), создаст базовую файловую структуру. Всё, можно колбасить. TARS работает на всех десктопных платформах.

    В ближайшем будущем сделаю yeoman-генератор.

    Прежде чем начать работу со сборщиком, рекомендую ознакомиться с документацией.

    Основные команды для сборки


    Всего есть две основные команды:
    • gulp build (или просто gulp);
    • gulp dev.

    Первая команда делает готовую сборку проекта, а вторая запускает TARS в режиме разработки. В dev-режиме проект собирается без минификаций и с запущенными вотчерами за файлами.

    Команды разбавлены небольшим количеством флагов:
    • gulp build (или просто gulp) (--min, --release, --ie8);
    • gulp dev (--lr, --tunnel, --ie8).

    С gulp build можно использовать ключ --min, и тогда в html подключатся минифицированные js- и css-файлы. При использовании ключа --release в html подключатся всё те же минифицированные файлы, в названии которых есть рандомный hash.

    С gulp dev используются ключи --lr для запуска livereload в браузере, который откроется автоматически (браузер можно выбрать в конфиге). Ключ --tunnel расшарит вёрстку с вашего локального компьютера во внешний веб. Вы получите ссылку в консоли, по которой вёрстка будет доступна в вебе.

    Также с любой командой можно использовать ключ --ie8, который запустит дополнительные таски для сборки с поддержкой браузера Internet Explorer 8. Браузер особенный, вот и workflow для него особенный.

    Все инструкции по установке находятся в документации.

    Структура проекта


    В папке «tars» находятся все файлы сборщика (встроенные и пользовательские таски с вотчерами, различные хэлперы) и папка с исходниками проекта (markup). В корне лежит конфиг сборщика, списки зависимостей для проекта, конфиг для проверки js code style и основной gulpfile.js.

    ├── gulpfile.js                 # gulpfile сборщика
    ├── tars-config.js              # Конфигурационный файл
    ├── package.json                # Зависимости TARS
    ├── user-package.json           # Пользовательские пакеты
    └── tars/                       # Таски и хелперы для gulp
        └── helpers/                # Хелперы
        └── tasks/                  # Основные таски
        └── user-tasks/             # Пользовательские таски
        └── watchers/               # Основные вотчеры
        └── user-watchers/          # Пользовательские вотчеры
    └── markup/                     # Основная папка с проектом
        └── modules/                # Модули
        └── pages/                  # Шаблоны страниц
        └── static/                 # Различная статика (css, js и т.п.)
    └── docs/                       # Документация
    


    Проект — это набор страниц (папка pages), набор модулей (папка modules) и папка с различной статикой (static, по умолчанию. Название можно сменить в конфиге).

    Страницы — самые простые шаблоны, в которые подключаются модули. Простейший пример модуля — menu или footer. Чтобы стало понятнее, в терминах БЭМ модуль — это блок. А если без БЭМ, то модуль — любая самостоятельная сущность на странице.

    exampleModule/                              # Пример модуля
        └── assets/                             # Различная статика для текущего модуля
        └── ie/                                 # Стили для ie8 и ie9 (ie9/ie8.scss|less|styl)
        └── data/                               # Папка для хранения данных для модуля
            ├── data.js                         # Данные для модуля в виде js-объекта
       ├── exampleModule.html                   # Html|Jade-представления модуля 
       ├── exampleModule.scss|less|styl         # Scss|Less|Stylus-представление модуля
       ├── exampleModule.js                     # Js-представление модуля
    


    Каждый модуль имеет своё html-, css- и js-представление, папку для различных файлов для модуля (картинки, видеофайлы и т.д.), папку для стилей браузеров IE8 и IE9, папку с файлом данных для модулей. Все перечисленные файлы и папки необязательны для модуля. Любой модуль может включать другие модули.

    Вовсе не обязательно, что модуль — отдельная сущность. Вы можете использовать модули так, как вам будет удобно.

    Папка со статикой может содержать в себе подкаталоги для хранения картинок, js-файлы библиотек и плагинов, файлы выбранного css-препроцессора + различные файлы, которые должны в итоге оказаться в корне проекта, например, фавиконка или robots.txt

    Обязательно прочтите, каким образом склеиваются JavaScript и CSS, — от этого зависит то, как нужно пользоваться файлами сборщика.

    Файловая структура создаётся автоматически при инициализации проекта. Она в целом неизменяемая, но есть ряд необязательных каталогов, плюс ряд опций для изменения имени уже существующих папок сборщика. Файловая структура подробно описана в документации.

    Для JavaScript созданы отдельные опции, в которых можно указать, откуда ещё нужно брать js для склейки. Таким образом, не нужно лезть в файлы сборщика, если вы хотите использовать какой-либо фреймворк, в котором есть не только такая сущность, как модуль (или представление, или директива, или что-то там ещё).

    Работа с шаблонами


    Предположим, что у нас есть страница, на которой есть верхнее, боковое и нижнее меню. Примерно такая:



    Меню очень похожи друг на друга, но имеют разные ссылки, небольшие различия в стилях. Далее будем говорить в терминах БЭМ. Каждое меню — это блок. Набросаем немного html для реализации меню, который в итоге мы положим в папку modules (modules/menu/menu.html):

    <nav class=”menu”>
        <ul class=”menu__list”>
            <li class=”menu__listItem”>
                <a href=”url” class=”menu__listItemLink”>title</a>
            </li>
            ...
        </ul>
    </nav>
    


    Я не буду приводить весь код, но очевидно, что портянка получается вполне солидной. Теперь вынесем все данные для этого меню (ссылки и названия пунктов меню) в отдельный файл (data/data.js в папке модуля):

    menu: {
        header: {
            mod: ‘header’,
            list: [
                {
                    url: firstLinkUrl,
                    title: firstLinkTitle
                }
                ...
            ]
        },
        side: {
            mod: side,
            list: [
                {
                    url: firstLinkUrl,
                    title: firstLinkTitle
                }
                ...
            ]
        },
        footer: {
            mod: footer,
            list: [
                {
                    url: firstLinkUrl,
                    title: firstLinkTitle
                }
                ...
            ]
        }
    }
    


    Теперь немного усовершенствуем наш шаблон для меню (используем handlebars):

    <nav class=”menu {{#if mod}} _{{mod}} {{/if}}”>
        <ul class=”menu__list”>
            {{#each list}}
                <li class=”menu__listItem”>
                    <a href=”{{ur}}” class=”menu__listItemLink”>{{title}}</a>
                </li>
            {{/each}}
        </ul>
    </nav>
    


    В этом случае добавился некий mod, с помощью которого мы сможем кастомизировать CSS для меню в зависимости от его положения.
    Осталось только подключить эти меню на странице:

    <html>
        <head></head>
        <body>
            <header>
                {{> menu/menu menu.header}}
            </header>
            <aside>
                {{> menu/menu menu.side}}
            </aside>
            <footer>
                {{> menu/menu menu.footer}}
            </footer>
        </body>
    </html>
    


    С помощью handlebars-хелпера «>» мы подключаем модуль menu с представлением menu (каждый модуль может иметь несколько представлений) на страницу и передаём ему определённые данные.

    Итого мы имеем 1 шаблон + 1 файл с данными для меню, который используется в двух разных местах. Таким образом можно реализовать модуль, который очень удобно переиспользовать. Остаётся только добавить, что такой же функционал реализован и для jade.

    Подготовка и хранение графики


    Сегодня существует много экранов с высокой плотностью пикселей. Разберёмся, что это значит.

    В качестве примера рассмотрим смартфоны IPhone 3GS и IPhone 4. У 3GS разрешение экрана 320x480, а у 4-ки — 640x960. Как мы видим, разрешение увеличилось ровно в два раза при той же диагонали, а значит пиксель стал меньше. Чтобы нивелировать эту разницу между размерами пикселей (а ведь именно пикселями мы управляем в CSS) появился параметр device-pixel-ratio (или dppx), который показывает, сколько реальных экранных пикселей содержится в неком логическом пикселе, которым мы оперируем в css. Например, для дисплея IPhone 4 этот параметр равен 2. Более подробно можно прочесть на сайте W3C.

    Предположим, у нас есть спрайт PNG-изображений. У таких картинок фиксированные размеры. Если мы разместим такой спрайт на экране IPhone 4, то каждый пиксель спрайта будет размыт на два экранных, а если размазывать такую картинку на количество пикселей в 2 раза большее, чем размеры картинки, то изображение будет выглядеть ужасно.

    Чтобы избавиться от этой проблемы, можно использовать изображение в 2 раза большего размера, при этом размер картинки в CSS задавать исходя из размера оригинального изображения (свойство background-size).

    На данный момент существуют экраны с dppx от 1 до 4 (скоро будут и выше). Готовить спрайты для четырёх размеров экранов — это очень много работы.

    Выручает SVG. Векторный, не зависит от dppx-экрана, отлично рендерится в современных (и не только) браузерах. Можно сделать только один размер, и это изображение будет выглядеть одинаково на всех экранах.

    К сожалению, SVG имеет несколько недостатков:
    • SVG плохо отображает радиальные и другие сложные градиенты (линейные отображаются отлично);
    • плохо отображаются сложные тени;
    • не отображается в IE8.

    Итого имеем два подхода: SVG для всего, чего можем. Для остального готовим PNG-изображения. Для IE8 будем просто растрировать SVG-изображения и готовить спрайт из них.

    Чтобы легко управлять этими подходами, были написаны два замечательных миксина (синтаксис SCSS):

        @include bg-svg($svg-image-name);  для SVG изображений;
        @include bg($png-image-name);  для PNG изображений.
    


    При этом для IE8 у нас всё сгенерируется и подключится автоматически, для png-изображений сгенерируются media-запросы, которые подключают определённые png-картинки в зависимости от типа экрана. Вообще, для IE8 и IE9 генерируются отдельные css-файлы. Файлы для IE8 создаются только в том случае, если мы запустили сборку с ключом --ie8.
    Пример использования миксинов:



    Можете представить по объёму сгенерированного кода, сколько работы было сделано автоматически.

    Более подробно о сборке графики можно почитать в документации, а сам подход отлично описан в презентации веб-разработчика Тимофея Чаптыкова.

    Пользовательские таски


    В TARS уже есть всё, что нужно для разработки проектов любой сложности, но всем не угодишь. У каждого может быть какая-то своя специфика, какие-то дополнительные задачи. Чтобы решить эту проблему, был создан шаблон пользовательского таска (tars/user-tasks/example-task.js). На его основе можно сделать свой таск, который легко встраивается в существующую инфраструктуру сборщика.

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

    Поскольку основной package.json (файл, в котором находятся зависимости сборщика) может изменяться самим сборщиком (например, при выполнении команды gulp update-deps), то пользовательские зависимости нужно хранить в отдельном месте. Для этого есть user-package.json. Синтаксис объявления зависимостей такой же, как и в основном package.json

    Также есть пример пользовательского вотчера в директории tars/user-watchers.

    Планы на будущее


    Есть планы по добавлению новых фич:
    • переехать на Gulp 4 версии;
    • добавить шаблонизаторы;
    • добавить пре- и пост-процессоров для CSS;
    • добавить поддержку ES6;
    • использовать Browserify или webpack.

    В ближайшем будущем выпустим версию 1.3.0 и сделаем перевод документации на английский язык (буквально уже на следующей неделе будет готово). Планы по выпуску новых версий можно посмотреть на GitHub.

    Забыл упомянуть, что это open source, поэтому жду ваших pull request'ов, вопросов по расширению функционала сборщика в issue. Продублирую прямую ссылку на репозиторий проекта.

    P.S.: 28–29 марта в Новосибирске пройдёт крупнейшая IT-конференция за Уралом — СodeFest. На этой конференции у TARS будет отдельный стенд. Если приедете на CodeFest — подходите, задавайте вопросы.
    2ГИС 200,70
    Карта города и справочник предприятий
    Поделиться публикацией
    Похожие публикации
    Комментарии 44
    • +1
      Под кат, плиз.
      • +2
        Крутая штука, но пробовать буду как генератор сделаете. Ибо лень архив качать, и как-то неправильно это.
      • +1
        Как то я не очень понял, а от какой именно рутины TARS избавляет? От разового добавления нужных тасков в gulpfile? Вот если эта штуковина могла бы помогать создать кастомную структуру проекта и представить что-то типа GUI для настройки задач и установки любых модулей — было бы круто. А так — мне не очень понятен смысл. Может это просто какая-то специфичная БЭМерская проблема решается? Я не критикую, просто понять пытаюсь…
        • 0
          Например, особенно заметна помощь при избавлении от рутины при подготовке графики. Достаточно просто сохранить SVG-файл в нужной директории, использовать миксин и все, изображение уже на странице, со всеми минификациями, поддержкой любых экранов и поддержкой IE8, если необходимо.
          Тоже касается и html, js, css. Все работает сразу из коробки. У меня есть сводная таблица с замерами времени верстки небольшого промо-сайта (7 страниц) без TARS (но с отдельными моментами, которые были автоматизированы) и с TARS. Разница оказалась ощутимой. Минимальный выигрыш был в работе с html — 2 часа (с 8 часов до 6), а максимальный — в работе с картинками. Там выигрыш составил 4 часа (с 6 часов до 2). По временным отрезкам можно примерно представить сложность проекта.
          Вы можете многое менять в структуре проекта, используя опции и доп. таски. Создание любой кастомной структуры с автоматической поддержкой в тасках — это конечная цель.
          По поводу GUI вопрос интересный, но крайне сложный. Есть подобные проекты с GUI (CodeKit, например). Но, признаюсь честно, пока совсем нет времени на создание хорошего, кроссплатформенного GUI. К тому же, я уверен, что с консолью так или иначе ладят все.
          Про установку модулей, есть мысли о том, чтобы автоматизировать этот процесс, сделать шаблон модуля, от которого можно было бы реализовать что-то свое и легко устанавливать в TARS. Это мысли на ближайшее будущее.
          В TARS нет никакой БЭМерской специфики. Каждый модуль можно использовать так, как захочется, я лишь в статье использовал БЭМ-терминологию. Просто разделение страницы на некие блоки/сущности/еще что-то — это просто хорошая практика, которая позволяет быстро разрабатывать и поддерживать проект. Вы сами вольны придумать назначение для модуля.
          Надеюсь ответил на все вопросы и сомнения.
          • 0
            Нет, я все еще не понял. Окружение проекта со всеми вотчерами, конкатами, минификаторами, оптимизаторами, автопрефиксами и прочим — настраивается один раз, и затем все это можно многократно переиспользовать. Можно взять готовое с помощью одного из Yeoman-овских генераторов, если уж совсем не заморачиваться. И это задача не на 4 часа. Тонкая настройка может быть перманентным процессом, но она также не отнимает много времени. При использовании модных веб-компонентов и Polymer-овского vulcanize, работа с шаблонами и html в целом — довольно приятное занятие. И я не понял с каким воркфлоу идет сравнение по времени, работы с картинками например, с оптимизацией вручную в фотошопе?
            • +1
              Мое решение предоставляет готовый сборщик, из которого каждый может использовать то, что нравится. Поверьте, далеко не все хотят заниматься настройкой окружения, сборщика и т.д. Есть те, кому нужно уже готовое решение.
              Отлично, если вы можете легко для себя настроить окружение так, как вам удобно. Возможно для вас нет смысла использовать TARS полностью, а стоит выдрать только отдельные таски или вообще его не использовать)
              • 0
                Сделали генератор, теперь, думаю польза стала более явная) github.com/tars/tars-cli
          • 0
            рандомный hash

            А чего не основанный на содержимом? Я вот беру конкатенированное содержимое, md5 от него и потом первые пять символов от полученного хэша. Использую в другом контексте, у меня движок сам всю эту рутину делает, но суть понятна, если вы обновляете один CSS файл и пересобираете проект — нет смысла менять все хэши, ибо пользователю придется всё это потом грузить заново, а так только изменившуюся часть.
            • 0
              Вот ещё, в коде для IE8 отличается только background-image, а генерируется весь блок, тоже как-то не оптимально получается.
              • 0
                На самом деле не только им. SVG-спрайт, в который собираются все SVG-изображения, может отличаться по компановке от спрайта растрированых SVG для IE8, значит уже как минимум два свойства различны. Возможно имеет смысл переиспользовать вычисленные размеры SVG-изображения для растрового, но подсчет размеров для растровых картинок не занимает много времени.
                Но на самом деле — это вообще не важно, так как для IE8 будет отдельный файл, в котором не будет стилей для подключения SVG, а в стилях для современных браузеров не будет стилей для IE8. На скрине они вместе лишь для наглядности.
              • 0
                Ошибся комментарием.
                Это ответ на предыдущий: «Отличная мысль, добро пожаловать в issue) Всегда рад хорошим идеям»
              • 0
                Артём,
                — «сборщик 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>
                



                А в целом, молодец (ы) :)
                • –1
                  «сборщик html-разметки» и вправду лучше подходит, пожалуй стоит заюзать, спасибо.
                  У каждого БЭМ свой) Это так, для примера лишь.

                  Главное, чтобы это на пользу было)
                  • +1
                    Проститие, не смог удержаться «HyperText Markup Language — Markup»
                    image
                • +1
                  Чем больше смотрю подобные сборщики, тем больше понимаю, что все таки под нужды компании нужно писать свои таски. Мы над своим работаем и улучшаем почти что из проекта в проект. А для продуктовых компаний так вообще писать «для себя» просто необходимость.
                  Но всё равно спасибо за ваше видение роли сборщика фронтенда.
                  • 0
                    Естественно, всем не угодишь. Поэтому добавлены пользовательские таски.
                    На самом деле, можно выкинуть все таски и заюзать систему хранения тасков отдельно. Были мысли вынести это отдельно, только вот не знал, будет ли кто-то это использовать в таком виде.
                  • +1
                    Устаревшие у вас инструменты для CSS. Нет ни одного плагина PostCSS, даже хотя бы Автопрефиксера (Google рекомендует только его для работы с префиксами).
                    • +1
                      Autoprefixer есть. Про PostCss уже есть задача по внедрению.
                    • +2
                      Мне кажется TARS и подобные инструменты очень специфичны. Да, вы сделали возможность всё менять, добавлять своё и кастомизировать как угодно, но опять же придётся разбираться не только с Gulp, а теперь ещё и с TARS, пусть это и всего лишь добавить 10-20 минут на каждую задачу вначале.
                      На мой взгляд, в каждой компании есть уже свой конвейер, который не сильно меняется от проекта к проекту и намного проще что-то изменить в нём. Да и строить сборщик на основе другого сборщика, который обретёт в будущем ещё один сборщик… какая-то абстракция на абстракции.
                      И тем не менее, работа проделана большая и думаю TARS найдёт своих пользователей :)
                      • 0
                        Вы на сборщик ExtJS посмотрите при возможности. После этого уже ничего не страшно ;)
                      • 0
                        Как раз сегодня ночью организовывал свои gulp task'и для React 13 + babel.
                        Приятно что вы заботитесь а кастомизации, но все-таки мне кажется что build система должна быть жестко разделена от продукта config файлом, и навязывать разработчику где ему хранить шаблоны, и как разбивать код на модули — очень не благородное дело. В случае с React здесь появляются различные конфликты например.

                        А так, спасибо)
                        • 0
                          Была мысль вынести паттерны путей до разных файлов сборщика в конфиг, но конфиг получился большим слишком, что стало страшно) Как считаете, было бы удобнее, если бы структуру описать можно было бы в виде этого одного конфига? Не пугались бы люди?)
                          • 0
                            Я думаю что это необходимо как минимум в виде опции. Есть масса подходов и платформ, где структура проекта достаточно жестко задается, при этом системы сборки там далеки от идеала.
                            Успехов, буду следить за обновлениями и по возможности с удовольствием попробую.
                        • 0
                          Gulp просто чудесен и разобраться в нем достаточно просто. Ничуть не оспариваю ваш труд (весьма полезный), но он скорее представляет академический интерес, так как все равно кто-то запилит таски для dev/stage/production с тестами и поэтессами.
                          Например я уже пишу на ES6 потому что это удобно и есть gulp-babel, а у вас его и bower все еще нет. Также не нашел упоминания base64 (есть плюсы и минусы, но до 32кб спрайтами устраивает).
                          И неплохо было бы добавить gulp-notify.
                          • 0
                            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-таск.
                          • 0
                            Можно взять www.npmjs.com/package/gulp-bower, www.npmjs.com/package/gulp-bower-files или же сконфигить директорию через .bowerrc
                            • 0
                              Спасибо за ссылки. Уже как раз есть мысли внедрить подобное.
                            • 0
                              Это – как раз то, к чему я так привык в generator-yeogurt, и чего мне не хватало, чтобы перейти на Gulp и, так скахать, в основной поток влиться. Благодарю от души!
                              Ещё и БЭМ пойму по пути. Шикарно.
                              JS-объекты с данными – тоже верх желаний, постоянно прикручиваю свой JSON с данными вёрстки, чтобы в Jade всё это не писать.
                            • 0
                              В TARS мне не нравится:

                              • отсутствие модульности (я говорю commonjs)
                              • отсутствие тестирования
                              • громоздкий

                              Ранее использовал gulp-starter от Vigetlabs, когда он еще на browserify был (теперь на webpack). Потом перешел на wepack + минимум gulp.

                              Как ни крутите, но гапловскими задачками вы вряд ли соберете фронтенд качественнее, чем webpack'ом. Также хочу предостеречь от browserify. С одной стороны, освоить его проще, но с другой — он ограниченный, бажный и потихоньку затухает.
                              • 0
                                Также в TARS неполностью реализован cache-busting: файлы шрифтов в стилях остаются без хеша.

                                • 0
                                  1) webpack уже почти в тестировании. 1.7.0 будет максимуму в начале той недельки;
                                  2) если речь идет о тестировании самого TARS, то это не так, сам TARS тестируется. Если речь о том, что workflow нет для тестирования проекта — это да. Задача есть, было бы неплохо, если бы кто-то помог с этим;
                                  3) Объясните, что это значит, пожалуйста.

                                  Про webpack я уже ответил. И тут вопрос не про качество, а про скорость сборки скорее.

                                  По поводу кеширования шрифтов: а зачем хеш для них нужен? Есть вероятность, что вы сделаете другой шрифт под тем же именем? У них внутри в любом случае свое имя зашито и ОС понимает, с каким шрифтом имеет дело исходя не только из названия шрифта. В общем про этот момент не понятно.
                                  • 0
                                    По поводу кеширования шрифтов: а зачем хеш для них нужен?

                                    Иконочные шрифты периодически обновляются, например, materialdesignicons или font-awesome, которые устаналиваются через bower или npm. Иногда в них меняются коды иконок. И если cache-busting применяется только к стилям, то клиент вместо "галочки" видит "крестик", вместо "котика" — "собачку" и т.п.
                                    К тому же, кроме шрифтов, вы не применяете cache-busting к картинкам background-image.
                                    • 0
                                      Согласен. Кажется я знаю, как это можно решить, добавлять хеш в имя папки со статикой, тогда не придется врсионировать каждый файл отдельно. Как вам идея?
                                      • 0
                                        Мне не нравится идея изменять названия папок и файлов. На то есть причины:
                                        • нельзя простым способом задеплоить ASP.NET проект, потому что невозможно добавить в проект файлы собранного фронтенда (пути к этим файлам меняются). Также получаем сложности с роутингом.
                                        • если меняются названия файлов, то отладчик в браузере будет закрывать старые версии этих файлов, будут теряться брейкпоинты, маппинг на файловую систему, позиция курсора.

                                        Куда лучше добавлять хеш в query string.
                                        • 0
                                          И главный вопрос: при обновлении одного шрифта браузеру придется обновить всю статику?
                                          • 0
                                            Погодите, хеш добавляется только при релизе. В разработке никакого хеша нет.
                                            • 0
                                              Я говорю о браузере конечного пользователя.
                                              • 0
                                                Во-первых, насколько часто у вас релизы происходят? Во-вторых, в чем проблема подгрузить новые ресурсы при первом входе?
                                                • 0
                                                  1. Суммарный пожатый фрондент весит 3.2 МБ. Релизы происходят по-разному: бывает раз в неделю, бывает раз в день.
                                                  2. Regular 3G 750 Кб/с грузит всю статику за 22 сек. Загрузка сопровождается прогресс-баром.
                                                  3. Зачем перегружать весь фронтенд, когда нужно обновить только часть? Только потому что TARS не может иначе?
                                                  • 0
                                                    TARS по умолчанию создает 1 хеш на все. С новым релизом хеш поменяется, это да. Никто не мешает этот механизм настроить так, как вам будет удобно.
                                                    Скажите, часто ли такое бывает, что вы правите только стили и релизите это? Скорее всего правится еще и JS, и шаблоны. Хотя вот щаблоны могут и не меняться. Часто ли вы меняете только шрифт и релизите?
                                        • 0
                                          А про громоздкость так и не ответили.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое