Почему Sass?

Ден Седерхольм 10 декабря 2013

Перед вами перевод первой главы книги «Sass For Web Designers» Дэна Седерхольма, которая вышла в серии A Book Apart. В числе других книг, мы рекомендуем эту для введения в CSS-препроцессоры. — Прим. редактора.

Я не хотел верить в 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) в книге «Программист-прагматик» (bkaprt.com/sass/1/) принцип DRY звучит так:

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

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

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

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

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

Так почему же так трудно работать с CSS?

Почему CSS имеет такие синтаксические ограничения, мы можем попытаться узнать из эссе соавтора CSS Берта Боса (bkaprt.com/sass/3/):

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

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

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

Что такое Sass

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

Краткое описание Sass (bkaprt.com/sass/4/) с сайта технологии:

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-ом!

Перевод оригинальной статьи «Why Sass?» Дэна Седерхольма (Dan Cederholm), опубликованной на сайте A List Apart. Переведено и опубликовано с разрешения автора.

Перевод выполнили: Наташа Арефьева и Юлия Бухвалова, редактура Вадима Макеева и Ольги Алексашенко.

Теги: ,

Комментарии +

  1. agat 10 декабря 2013 в 12:55

    Пример с:

    
    @include default-type;
    
    

    Не самый оптимальный, лучше подошла бы конструкция с использованием @extend.

  2. Владимир 11 декабря 2013 в 4:37

    Спасибо за статью.

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

    Эта книга есть на русском? А то заинтриговали и, что дальше?..

  3. Вадим Макеев 11 декабря 2013 в 14:55

    Владимир, к сожалению, книга пока не переведена на русский. Может быть издательство «МИФ», которое переводило серию A Book Apart когда-нибудь сделает это.

  4. Алексей 21 декабря 2013 в 2:25

    Почему-то когда заходит речь про Less и Saas одним из первых преимуществ всегда идет рассказ "как здорово поменять цвет по всему документу в одном месте". Хотя не менее здорово и быстро сделать это можно используя CTRL+H в Sublime или Notepad.

  5. alex 22 января 2014 в 2:52

    Ни о чем.
    - Я боялся SASS потому что там консоль, там руби, там темный лес, там...
    - Теперь я не боюсь SASS потому что у меня есть переменные, миксины и прочая ерунда, которой я даже не пользуюсь.

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

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

  6. weliant 30 января 2014 в 15:38

    Отличная статья! Недавно наткнулась на Less, а сейчас на Sass, явно надо взять на вооружение, тем более сам Дэн Седерхольм работает с этим. Да, он у меня в пример! Отличные у него книги, так что всем рекомендую!)

  7. Юрий 28 октября 2014 в 13:34

    to agat:
    @include default-type; - почему это @extend лучше подошла бы?
    Тут правильно используется конструкция @include.

  8. Andrey 31 октября 2014 в 0:12

    to Alex
    Почему вы решили что на вас орут?
    Когда вы лепите миксины, убираете дублирование кода, используете переменные, то занимаетесь оптимизацией своего кода. Если у вас это плохо получается и вы считаете что зря тратите свое время, то умные люди кое что за вас уже придумали. Существуют библиотеки с готовыми структурами из переменных и миксинов, позволяющие строить гибкие сетки для адаптивного дизайна со сколь угодно сложной разметкой, обеспечивают кроссбраузерность и много еще чего, почитайте про Susy и поймете что если просто тупо делать дело, то можно быстро и безнадежно отстать. Впрочем, учитывая что ваш коммент написан год назад, я надеюсь ваше мнение уже поменялось.

Перейти к началу