Остановите войну в Украине!

Почему Sass?

Перевод «Why Sass?»

Перевод Наталья Арефьева

Редактура Ольга Алексашенко Вадим Макеев Юлия Бухвалова

Я не хотел верить в Sass. «Я пишу стили руками! Мне не нужна помощь. Я не хочу усложнять мой рабочий процесс! Отстаньте от меня!»

Так, во всяком случае, я думал. Но на самом деле, Sass, как и другие препроцессоры, может быть могущественным союзником — инструментом, который любой верстальщик может легко использовать в своей ежедневной работе. Мне потребовалось совсем немного времени, чтобы разобраться в нем, и я действительно рад, что сделал это.

И именно поэтому я захотел написать эту небольшую книгу. Рассказать о том, как я начал использовать Sass, чтобы сделать разработку кода более эффективной, и сохранил при этом рабочий процесс, которому привык следовать на протяжении последних десяти лет. Изначально у меня было много неправильных представлений о Sass, которые удерживали меня от того, чтобы начать им пользоваться. Я беспокоился, что мне придется полностью изменить привычные способы создания и организации стилей. Иногда CSS бывает довольно хрупким, и это объясняет желание разработчиков как-то защитить то, что они делают. Смогу ли я справиться с этим?

Хм…

Итак, я здесь, чтобы показать вам, что Sass не нарушит ваш привычный рабочий процесс, и при этом он может облегчить вашу жизнь. В книге я коснусь различных аспектов Sass: как его установить, как использовать; расскажу, как он помог мне в моих собственных проектах. Если повезет, я смогу сделать так, чтобы вы тоже в него поверили.

Sass: короткая презентацияСкопировать ссылку

Вам когда-нибудь надо было изменить в стилях, скажем, цвет, и при этом обнаруживалось, что вы вынуждены найти и заменить его значение во многих местах? Вам хотелось бы , чтобы CSS позволял вам сделать это вот так?

$brand-color: #fc3;

a {
    color: $brand-color;
}

nav {
    background-color: $brand-color;
}

Что, если бы вы могли изменить значение в одном месте, а оно бы поменялось во всем документе? С Sass это возможно.

Или как насчет повторяющихся блоков правил, которые используются в разных местах таблицы стилей?

p {
    margin-bottom: 20px;
    font-size: 14px;
    line-height: 1.5;
}

footer {
    margin-bottom: 20px;
    font-size: 14px;
    line-height: 1.5;
}

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

@mixin default-type {
    margin-bottom: 20px;
    font-size: 14px;
    line-height: 1.5;
}

p {
    @include default-type;
}

footer {
    @include default-type;
}

Всё это тоже Sass! И два этих очень простых примера демонстрируют лишь небольшую часть возможностей Sass, который может сделать разработку стилей более быстрой, легкой и гибкой. Он желанный помощник в мире веб-дизайна, потому что каждый, кто создает сайты, знает, что…

CSS сложенСкопировать ссылку

Ну правда, изучить CSS не просто. Разобраться, что делает каждое свойство, как работает каскад, какие браузеры что поддерживают, селекторы, режимы совместимости, и т.п. Всё это не просто. Добавьте сюда сложность интерфейсов, которые мы разрабатываем и поддерживаем — погодите, почему мы снова и снова это делаем?! Это паззл, и некоторые из нас наслаждаются его финальной завершенностью.

Частично проблема в том, что изначально CSS не был предназначен для того, что мы делаем сегодня с его помощью. Конечно, прогресс движется достаточно быстро благодаря стремительному развитию браузеров, внедрению поддержки CSS3 и так далее. Но мы все еще вынуждены полагаться на техники, которые, несмотря на их полезность, являются хаками. Свойство float, например, было создано для того, чтобы просто выравнивать картинки внутри текстового блока. И только. Тем не менее, мы вынуждены использовать это свойство не по назначению, чтобы создавать раскладку для полноценных интерфейсов.

К тому же, в наших таблицах стилей очень много повторений. Цвета, шрифты, часто используемые группы свойств и т.п. Типичный CSS файл имеет линейную организацию — такой тип кода заставляет «объектно-ориентированного» программиста рвать на себе волосы. (Я не «объектно-ориентированный» программист, но у меня осталось совсем немного волос. Понимайте, как хотите.)

Поскольку интерфейсы и веб-приложения становятся более сложными, мы ставим с ног на голову изначальное предназначение CSS, чтобы сделать вещи, о которых раньше нельзя было и мечтать. Мы хитрим.

К счастью, сейчас браузеры внедряют новые возможности CSS гораздо быстрее, чем раньше, добавляются более эффективные и мощные свойства и селекторы, решающие проблемы, которые подбрасывает нам современный веб. Это новые способы раскладки в CSS3, border-radius, box-shadow, продвинутые селекторы, transitions, transforms, animation и многое другое. Это удивительное время. И всё равно в CSS ещё многого не хватает. Есть ещё пробелы, которые предстоит заполнить, и тогда жизнь разработчиков станет гораздо проще.

Принцип DRYСкопировать ссылку

Если мы заглянем в мир разработки ПО (я предпочитаю именно заглянуть, а не оставаться там), мы сразу заметим, что организация кода, переменные, константы, компоненты и т.п. являются неотъемлемой, ключевой частью работы тех, кто разрабатывает сложные системы.

Вы, возможно, слышали о принципе «не повторяй себя» (DRY). Придуманный и описанный Дэвидом Томасом (Dave Thomas) и Эндрю Хантом (Andy Hunt) в книге «Программист-прагматик» принцип DRY звучит так:

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

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

CSS — это всё что угодно, но только не DRY. Временами он может быть забит под завязку повторяющимися правилами, объявлениями и значениями. Мы всё время пишем одни и те же куски кода для цветов, шрифтов и часто используемых паттернов в наших таблицах стилей. Один взгляд на большой CSS-файл — и программист, привычный к коду, следующему принципу DRY, разрыдается, сначала от недоумения, потом от разочарования.

«Как, черт возьми, вы это поддерживаете?» — спросит он.

«Это ты еще не слышал про баги в IE», — ответите вы с некоторой долей самоуничижения.

Так почему же так трудно работать с CSS?Скопировать ссылку

Почему CSS имеет такие синтаксические ограничения, мы можем попытаться узнать из эссе соавтора CSS Берта Боса:

В CSS нет огромного количества мощных возможностей, которые есть в языках программирования: макросов, переменных, символических констант, условий, выражений и т.п. Всё потому, что богатые возможности языка дают продвинутым разработчикам больше свободы, в то время как менее продвинутые пользователи просто запутаются; или, что более вероятно, будут настолько напуганы, что даже не притронутся к CSS. Это баланс. И для CSS он имеет особенное значение.

Архитекторы CSS с самого начала заботились о доступности технологии. Они хотели (совершенно справедливо), чтобы как можно больше людей могли создавать сайты. Они хотели, чтобы CSS был достаточно мощен, чтобы можно было создавать стили для веб-страниц и отделять контент от оформления, и в то же время, был достаточно простым для понимания и использования. Я безусловно уважаю это решение. В то же время, у нас есть задачи, и эти задачи становятся все более сложными, в них больше нюансов и больше требований к поддержке и возможности дальнейшего развития.

К счастью, есть способы справиться с этим, и один из них — Sass.

Что такое SassСкопировать ссылку

Sass — это препроцессор, прослойка между таблицами стилей, которые вы пишете, и css-файлами, которые вы отдаете браузеру. Sass (сокращение от Syntactically Awesome Stylesheets — Синтаксически Потрясающие Таблицы стилей) заполняет те самые пробелы в языке CSS, позволяя вам писать код по принципу DRY, то есть, быстрее, эффективнее и проще в поддержке.

Краткое описание Sass с сайта технологии:

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

Итак, пока обычный CSS все еще не позволяет использовать такие вещи как переменные, примеси (mixins — повторяющиеся блоки стилей) и другие плюшки, Sass дает нам такую возможность, и даже больше — делает возможной «суперфункциональность» в дополнение к обычному CSS. Затем он компилирует ваш код в привычный CSS-файл с помощью командной строки или плагинов для фреймворка.

Если быть точнее, Sass — это расширение CSS3, и его SCSS-синтаксис («Sassy CSS»), о котором мы будем говорить — надстройка над CSS3. Это означает, что любой валидный CSS-документ также является валидным SCSS-документом. Возможность «быстро вникнуть» — неотъемлемая часть Sass. Начать использовать синтаксис SCSS легко, более того, вы можете начать использовать его в столь малых дозах, как захотите. Что также означает, что преобразование существующих стилей из CSS в SCSS можно производить поэтапно, по мере того, как вы будете больше узнавать Sass.

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

Более того, Sass помогает CSS становиться лучше. Некоторые возможности, которые немыслимы сегодня без препроцессоров, уже сейчас дают авторам CSS живую реализацию и поле для экспериментов. Позже, если это будет иметь смысл, конкретные возможности Sass могут серьезно повлиять на спецификации CSS.

Заблуждения о SassСкопировать ссылку

Я уже говорил раньше, что не очень-то хотел попробовать Sass. Отчасти причиной было большое количество заблуждений, которые у меня были до начала его использования. «Должен ли я знать Ruby и быть продвинутым пользователем консоли?» «Придется ли мне полностью изменить способ, которым я сейчас пишу CSS?» «Не станет ли конечный CSS раздутым и нечитаемым?»

К счастью, ответ на каждый из этих вопросов, конечно — «нет». Но я вижу, как эти вопросы всплывают каждый раз, когда кто-то упоминает Sass в интернете. Давайте проясним некоторые моменты.

Я боюсь командной строки!Скопировать ссылку

Едва ли меня можно назвать экспертом по использованию командной строки, но я нахватался каких-то знаний то тут, то там за эти годы. Я не боюсь с помощью консоли перемещаться по файловой системе, использовать Git команды и т.п.

Тем не менее, я понимаю дизайнеров и фронтенд-разработчиков, не желающих иметь дела с командной строкой. Фобия командной строки действительно существует в некоторых головах. Для Sass использование командной строки сводится к одной команде — и этого достаточно. Более того, существуют приложения и фреймворки, которые избавят вас от необходимости пользоваться командной строкой (я расскажу о них в следующей главе).

Так что даже если вы избегаете командной строки, это не помешает вам попробовать Sass.

Я не хочу менять свои привычки в написании CSSСкопировать ссылку

Да, я страдал и от этого заблуждения. Для меня важно, как создаются мои таблицы стилей и как они организованы. Есть целый набор личных скиллов, которые помогают создавать документы. Но помните, что с тех пор, как SCSS стал расширением CSS3, вам не придется менять ваши привычки. Комментирование, отступы — всё ваше форматирование может оставаться неизменными при работе с .scss файлами. Как только я это понял, я смог смело двигаться дальше.

Я не хочу менять свои привычки в организации стилей!Скопировать ссылку

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

Окей, теперь мы знаем немного больше о том, что нам предстоит. Давайте же получим от этого удовольствие. Я думаю, что возможности Sass вас удивят. В следующей главе мы узнаем, как встроить Sass в рабочий процесс, и как легко его использовать с помощью командной строки или приложения. Давайте займемся Sass-ом!