Что такое sass

Sass - это препроцессорный язык, расширяющий возможности стандартного css. Он позволяет использовать переменные, вложенные правила, mixins, встроенный импорт, и многое другое. Sass полностью совместим с css. Он помогает держать стили хорошо организованными, делает их более читаемыми и компактными. В купе с библиотекой compass, позволяет избавиться от css3 префиксов для разных браузеров, что делает его очень удобным.

Существует старый синтаксис sass и новый. Старый синтаксис ближе к языку ruby. Новый синтаксис более приближен к языку css. Он более понятен для верстальщиков, и в дальнейшем именно он будет описываться на данном сайте.

Я постараюсь сделать свой сайт доступным для большого количества людей. Начинающим верстальщикам, я объясню как можно упростить себе жизнь и сразу верстать на sass-е. Людям у которых уже есть опыт верстки, и которые хотят перейти на какой-нибудь язык препроцессора, я объясню почему стоит выбрать именно sass.

Основные препроцессоры

• prepros. Сейчас это наиболее популярная программа для компиляции sass или less файлов. Подходит больше для новичков.

• koala. По сути тоже самое, что и первая программа, но более старая.

• ruby. Использовать ruby советует официальная документация. Сразу нужно отметить, что файлы таким образом компилироваться будут достаточно долго. Данный способ не совсем удобный. Я не рекомендую им пользоваться.

• node.js. Для того, чтобы использовать его как препроцессор, можно установить как дополнительный модуль, так и использовать инструменты для сборки js проектов, такие как grunt или gulp. Я советую использовать gulp для компиляции sass файлов.

Сравнение less и sass

В интернете написано много статей про сравнение less и sass. К сожалению эти статьи старые, и сейчас не являются актуальными.

В одной статье на хабре говорится, что у sass есть сompass, поэтому он лучше. В другой говорилось, что для less есть twitter bootstrap, и он лучше сompass. Что я могу сказать, новичок разницы между twitter bootstrap и compass не увидит. С недавних пор twitter bootstrap есть и на sass (это для фанатов bootstrap). По моему мнению compass все-таки лучше. Почему он лучше? Он более профессиональный. К примеру, twitter bootstrap в своих mixin-ах использует такой метод clearfix-а:

Будем называть его clearfix TB, хотя придумал его Nicolas Gallagher и называется он micro clearfix.

Когда я начинал верстать clearfix был таким:

Будем называть его старым методом clearfix-а.

На мой вопрос почему в twitter bootstrap используется именно этот метод clearfix-а. Один front-end разработчик (фанат LESS-а и bootstrap-а), с пеной у рта стал мне доказывать, что обычный clearfix г...но, он морально устарел, имеет кучу багов (притом ни одного бага назвать не смог). Где-то на форумах gitHub-а написано много блогов почему clearfix TB лучше, и стоит пользоваться только им. Это же twitter bootstrap, они все знают лучше. Я просмотрел кучу статей и могу с уверенностью сказать, что особой разницы нет. Метод clearfix TB не лучше и не хуже старого clearfix-a, просто он позволяет избавиться от "вертикального схлопывания". В большинстве случаев, я не вижу проблемы в вертикальном схлопывании, это нормальное поведение браузера. Нужно просто уметь им пользоваться.

Twitter bootstrap не дает вариантов для выбора, это лучше и все. Человек который верстает с его помощью, он как бы связывает себя, вынужден использовать решения twitter bootstrap и ограничивает себя этими решениями. В библиотеке compass присутствуют оба clearfix-а. Нужно мне избавиться от вертикального схлопывания, я использую clearfix TB. Если не нужно, использую старый clearfix. К примеру, на странице много разно-оформленных блоков, между ними одинаковый вертикальный отступ. Этот отступ больше, чем отступ заголовков и абзацев, один из блоков содержит плавающиий элемент. В нем картинка слева, справо описание к этой картинки. Картинка сделана float-ом, описание просто дивом, float тут не нужен, просто margin или padding слева на длинну картинки. Описание естественно содержит абзацы. При использовании clearfix TB самый верхний заголовок описания окажется ниже картинки, ведь вертикальное схлопывание не происходит. Для верхнего абзаца мне придется создавать дополнительный класс. Если он выглядит по другому (заголовок блока) это приемлемо, а если он выглядит также как и другие абзацы? Всего этого можно избежать если использовать старый метод clearfix-a. Происходит схлопывание, и верхний абзац с картинкой становятся на одном уровне.

На мой взгляд хороший верстальщик должен понимать что он делает, почему используется именно эта технология. Отсюда вывод, twitter bootstrap нужен верстальщикам которым нужны быстрые решения, те думать не надо. Как говорится хренак, хренак и продакшн:). Compass, для верстальщиков которые понимают, что они делают и какого эффекта хотят достичь.

Я стал использовать sass, так как в данном языке есть метом @extend. Что он делает? Представьте, что вы сверстали сайт на sass-е и вам нужно отдать его программисту. Вы верстаете в свободное время, к примеру вечерами. Обычный фриланс. Вам это нравится, да и за это платят деньги. Этот сайт вы серьезно поддерживаете. И вам нужно не просто его сверстать, а еще и как-то поддерживать нормально. Грубо говоря происходит небольшой редизайн, к примеру зимний дизайн сайта перед новым годом. Меняются основные цвета сайта. Меняется цвет ссылок, этот же цвет совпадает с цветом в хедере, левом меню и красиво оформленных блоках. Этим ограничимся, понятно, что если это крупный портал, то там много чего изменится. Как правило, если программист серьезно занимается back-end, то про sass он ничего не слышал. Работать с препроцессором он не умеет. Вам нужно отдать ему готовый css так, чтобы его можно было в дальнейшем удобно использовать уже на готовой CMS-ке. Про переменные придется забыть. При интеграции с CMS-ой он допишет много стилей, так что sass файл и css будут отличаться. Если вы хороший, опытный верстальщик, то при верстке новых макетов, вы не сразу начинаете верстать, а перед этим просматриваете полученные макеты и подмечаете схожие элементы. Одинаковый цвет ссылок, хедера, левого меню и красиво офомленных блоков вы сразу подметили. Естественно, чтобы лучше работать с сайтом эти цвета нужно сгруппировать.

Метод @extend как раз для этого и нужен.

Данный метод существенно упрощает работу верстальщика. Конечно можно самому сгруппировать одинаковые свойства, но так удобнее. Обычно, я где-то в самом верху описываю общие классы (потом с css-ой будет проще работать), а если сайт очень большой, то и вообще могу вынести их в отдельный файл. В примере, это общий класс .linkColor. Как правило, я группирую такие свойства как border-radius, border-color, background-color, color и font-family. Как правило в дизайне хедер, футер, левое меню и контентная часть имеют разные шрифты, но в контентной части находятся блоки со шрифтами из левого меню или хедера.

В less-е начиная с версии 1.4.0 тоже появился метод extend, но мало кто им пользуется. В sass-е данный метод был с самого начала. По крайней мере, когда я узнал, что данный метод есть у sass-а, в less-е его еще не было. Это как раз и была причина по которой я подумал о том, чтобы перейти с less-а на sass. Вообще, с появлением синтаксиса scss прослеживается тенденция, что разработчики less-а все больше воруют берут идеи из sass-a. К примеру логика. Когда я только начинал верстать в less-е логики не было.

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

Less и sass имеют разный синтаксис. В less-е переменная определяется через @, а в sass-е через $. Все бы хорошо, но @ используется в css. Это и media queries, и некоторые новые свойства css (@keyframes к примеру) и некоторые префиксы для разных браузеров (@-webkit, @-moz, @-ms к сожелению пока без этого никак). Естественно при компиляции less файлов возникают проблемы. К примеру, чтобы умешьшить количество запросов на сервер, я все css компилирую в одну большую css-ку. Что на less-е, что на sass-е это делается @import-ом. У меня есть один файл в котором @import-ом подключаются разные файлы (less это, или sass файлы не важно, я могу настроить и то, и то), дальше я watcher-ом просматриваю изменения в этих файлах и компилирую css при изменении любого из них. Так вот, less таким образом выдавал мне ошибку, когда я пытался скомпилировать css-ку fancybox. Там, если я не ошибаюсь был фильтр для старого эксплорера, который содержал @. На этом компилятор less-а штопорился, ведь для less @ это переменная. Ну это не проблема, старый ie мне был не нужен, я этот фильтр удалил, все скомпилировалось хорошо. И действительно все было хорошо пока...

У меня есть друзья. Однажды они делали сайт, для одной рекламной компании. Сайт содержит вид моего прекрасного города. Но это же рекламная компания, не интересно просто сделать сайт, нужно как-то покреативить. Мы решили немножко его оживить. Посмотрите на него (если у вас маленькое разрешение монитора, то подождите минуту, должен вылетить шарик). На дворе 2014 год, не имеет смысла делать анимацию на js, если можно сделать ее на css3. Равняться на 9 IE тоже смысла не было, ну не вылетит шарик, ну и ладно. Заказчик тоже был не против.

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

Ниже я приведу код, который описывает движения шарика (код без префиксов).

Для того, чтобы все это работало в разных браузерах для свойства animation нужно будет добавить префиксы -o-animation, -moz-animation, -webkit-animation. Это впринципе не трудно. А вот со свойством @keyframe сложнее. Мне нужно будет помимо префиксов @-webkit-, @-moz-, @-ms- еще и код продублировать. Сразу нужно сказать, что первоначально движение шарика и его начальная точка были другими. Шарик стартовал с середины экрана, ведь не у всех же широкие мониторы. Кто-то может эту анимацию грубо говоря и не дождаться. Вообще его траектория менялась раза 4. Тогда я верстал на less-е, но уже начал интересоваться sass-ом, после этого я как раз на него полностью перешел. Мне хотелось описать анимацию один раз, а не дублировать ее по 4 раза. Естественно я планировал для @keyframes написать какой-нибудь mixin. В итоге скажу так, ничего у меня не получилось. Mixin не получилось написать так как less думал, что @keyframes это переменная. Написать @keyframes с префиксами и вставить туда mixin с анимацией тоже не вышло. Скажу фанатам less-а, решение я нашел. Есть такая библиотека less hat. С ней мою анимацию можно осуществить на less-е. А вот теперь я приведу mixin less-а и mixin sass-а.

По моему, это хороший пример того, как необдуманная конструкция может осложнить жизнь разработчика. С самого начала разработчики less-а с объявлением переменной ошиблись. Могу предположить, что в будующем будут появляться другие интересные вещи вроде свойства @keyframes. На sass-е я без проблем смогу написать для них mixin. А вот на less-е мне придется ждать разработчиков less hat, что не есть хорошо.

Защитники less-а, приводят довод, что порог вхождения в less меньше чем в sass. Новичку будет проще его освоить. Давайте посмотрим, что новичку будет проще освоить.

Я привел основные конструкции, кроме циклов. Первое, что бросается в глаза, это разный синтаксис. По разному объявляются переменные и логические конструкции. Не знаю как у других, но у меня не возникает ощущения, что less проще и новичок быстрее его освоит. Less - это такой же препроцессорный язык. Он создавался как ответ на старый синтаксис sass. Напомню, что старый синтаксис sass был более приближен к языку ruby. Less практически все полезные идеи брал из sass, поэтому многие вещи похожи, единственное пишутся по другому. Никак нельзя сказать, что less проще. Правильнее сказать он имеет все те же конструкции, что и sass, но пишутся эти конструкции по другому. Сразу бросается в глаза, что less-ие конструкции выглядят короче sass-их. Это от того, что sass более структурный. На форумах говорится, что less более лаконичен чем sass, и это его плюс. Я же в этом плюса не вижу, ну используется в less-е & when вместо @if, ну запись mixin-а выглядит короче, разве это можно назвать плюсом? Просто синтаксис другой. Это не плюс и не минус. В less-ая быстрота записи идет в ущерб четкости и структурности. Когда проект маленький и обслуживает его один человек, возможно это и дает какие-то плюсы. Но вот когда проект большой, и обслуживает его несколько человек то тут из-за less-ой "лаконичности" начинаются проблемы.

Less-ие mixin-ы в коде, особенно если есть большая вложенность сразу не увидишь, они же пишутся как классы, соответственно любой редактор подсветит их как классы (не правда ли логично). Чужой проект замучаешься прокручивать пока поймешь что в нем и как. Sass-ие mixin-ы объявляются через @include, соответственно сразу понятно что здесь какая-то логика. Обращаясь к нашему примеру, у нас есть mixin size который задает размеры для верхнего логотипа. Давайте представим, что этот mixin задает размеры для какого-то блока, где-то в середине кода. Кода у нас много. К этому блоку прописано много свойств. Мне нужно эти размеры изменить. Первым делом я буду искать width и height. Естественно ничего я не найду. Mixim подсвечивается как класс, его я не сразу увижу. В итоге я буду долго менять размеры. На sass-е все проще. Я замечу @include, пойму что это mixin, увижу, что числа в нем похожи на длинну и высоту моего блока. В итоге на sass-е я размеры блока поменяю быстрее чем на less-е. На больших проектах sass-ая структурность облегчает жизнь. Все что я выше описал, сложно для восприятия пока с этим не столкнешься.

Когда я только начинал изучать less, логики в нем не было. На форумах это даже в плюс приводили. Зачем она нужна? А спустя какое-то время я просматриваю less-ие новинки и вижу логические конструкции. На самом деле, любой человек изучающий less или sass со временем будет ее использовать. Это вопрос опыта. У sass логика была с самого начала. Я занимаюсь front-end разработкой, мне очень нравится делать анимацию на js. На js я программирую с 2012 года. Sass-ие конструции @if, @else, @else if мне более понятны чем less-ие when, when not. У меня так бывало, что я пишу какой-нибудь плагин, время уже позднее. Нужно что-то поправить на less-е, я его смотрю и логику не вижу. На js ведь тоже if, else. Less-ие конструкции после работы с js я не воспринимал. Возможно & when, & when not и понятны, но для чего их вводить если есть if, else. Я не буду касаться серьезной front-end разработки, но мне кажется, что любой, даже самый начинающий верстальщик так или иначе знаком c js. Хотя бы на уровне подключения плагина. Раз знаком, значит элементарные логические конструкции языка должен знать. В случае с less-ом это вводит лишнюю неразбериху. Ну да это мое восприятие, если человек только начал заниматься версткой, до front-end пока не дорос, он не будет лезть в логику на данных языках.

Какой из всего этого можно сделать вывод, less он не проще чем sass, просто он менее структурный и имеет более короткие языковые конструкции. Новичок на изучение sass-а потратит не больше времени чем на изучение less-а. Более крупные проекты на less-е сложнее обслуживать чем на sass-е, особенно если проект большой и обслуживают его несколько человек. Со временем, чем больше молодой верстальщик будет развиваться, он будет хотеть большего. Писать свои плагины на js, освоить какую-нибудь cms-ку (хотя бы простенькая интеграция). И если он действительно любит верстать. То он подумает о том, чтобы написать свой простенький css-framework (он будет очень простым, но хотя бы чуть-чуть сократит время разработки). И вот тут-то он и увидит, что less немного не то. Он создавался как аналог старого синтаксиса sass, хотел быть более приближен к css, но вот следом за второй версией css вышла третья. Там много всего появилось, а вот less не развивался с того времени (воровство идей из sass-а не тот путь развития, лучше бы свое придумали). На мой взгляд, чтобы его оживить, его нужно по новому переписать. Переменные по другому объявить, взять логические конструкции такие какие есть во всех нормальных языказ программирования вместо своих & when, & when not.

На одном форуме, все споры o less и sass заканчивались тем, что sass удобный, но время компиляции очень большое. Это сводит все его плюсы на нет. Действительно, если пользоваться sass-ой документацией, установить ruby, то время компиляции будет достаточно большим. Вот средний проект - gaudi. Никаких особых наворотов тут нет. Итоговая css-ка после компиляции составляет 1000 строчек (каждое свойство css идет с новой строки). В качестве библиотеки mixin-ов используется библиотека compass, один файл с собственными mixin-ми и 2 файла с плагинами. Как видите все просто. Но когда я его компилировал через ruby, у меня время компиляции доходило до 2-3 секунд. Это много. Сверстал что-то, сохранил, и жди 2-3 секунды. Это меня не устраивало. Мне понравился sass за его четкость и структурированность. Но на less-е у меня такие проекты компилировались за милисекунды. Это средний проект, а если бы проект был большим, 2-3 секундами не обошлось. Я уже хотел его забросить. Но однажды я обратил внимание на такой сборщик проектов как gulp. У него есть плагин gulp-sass. Я его установил, по новой скомпилировал проект. Время первой компиляции заняло 986 милисекунд. А все последующие изменения у меня занимали 2-3 милисекунды. Он очень быстрый. Можно сказать, что используя gulp возникает ощущение, что работаешь с обычной css-ой, а не с scss файлом. Таким образом вопрос о времени компиляции у меня отпал.

Кто-то при сравнении less и sass учитывает сообщества обоих языков. Сколько их скачивают с gitHub. Потом говорят, что less круче, его и скачивает больше народа и сообщество его больше. На мой взгляд это не показатель. Сообщество может быть каким угодно большим, но если оно состоит из новичков, то толку от такого сообщества ноль. То, что его скачивают больше говорит о том, что less более раскручен в интернете. Но это совсем не показатель качества, это показатель хорошей рекламы, не более. В начале 20 века, после первой мировой войны, американцы употребляли лекарство содержащее радий. Его рекламировали как средство от ревматизма. И действительно радий как радиактивный элемент разрушал кости, людям его употреблявшим было не до ревматизма. Все прекратилось, когда умер один известный 51 летний политик. Это хороший пример рекламы. Выше я уже описывал, недостатки less-а. Это и отсутствие четкого видения развития (многие идеи воруют из sass), и проблемы с непродуманной конструкцией языка (объявление переменной). Для less есть даже библиотека less hat, хотя на самом деле это не библиотека а набор заплаток для less-а, так как дальше он без заплаток развиваться не может. Если кому это мнтересно, посмотрите mixin-ы less hat, большую часть этих mixin-ов вы сами реализовать не сможете. @keyframes это только одно свойство которое без less hat не реализуешь. Проблем с ним много. Невольно возникает вопрос, а нужно это все? У sass есть синтаксис scss, он приближен не к ruby, а к обычному css. Он структурный и понятный, на нем написаны такие css-framework-и как zurb foundation, gumby, bourbon, и это далеко не полный список. Конечно же нельзя обойти внимание и прекрасную библиотеку compass которая полнее twitter bootstrap.

Для многих верстальщиков и front-end разработчиков основным фактором мешающим перейти на sass является отсутствие русской документации по нему. На страницах данного сайта я постараюсь исправить этот недочет.