Лень двигатель прогресса. Хороший пример - принцип DRY - Don"t repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.

• Перевод

«Какой препроцессорный язык стоит использовать для CSS?» является очень актуальным вопросом в последнее время. Несколько раз меня спрашивали об этом лично, и казалось бы, каждые пару дней этот вопрос поднимался в сети. Очень приятно что беседа перешла из темы о плюсах и минусах препроцессинга к обсуждению какой же язык является лучшим. За дело!

Если быть кратким: SASS.

Немного развернутый ответ: SASS лучше по всем пунктам, но если вы уже счастливы с LESS - это круто, по крайней мере вы уже упростили себе жизнь используя препроцессинг.

График обучения с Ruby и командной строкой

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

Победитель: нет.

В помощь CSS3

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

Так что все это сводится к следующему: у SASS есть Compass, а у LESS его нет . На самом деле все немного запутанней. Все попытки создать проект типа Compass для LESS потерпели неудачу. Дело в том, что LESS не является достаточно сильным языком, что бы сделать это корректно. Немного подробней будет ниже.

Победитель: SASS

Способности языка: логика/циклы

LESS позволяет создавать «защищенные примеси». Эти примеси вступят в силу только в случае если условие верно. Допустим вы захотите поменять цвет фона, который будет зависеть от текущего цвета текста. Если цвет текста «достаточно светлый» вы, наверное, захотите сделать темный фон. Если же он «достаточно темный» - вы захотите светлый фон. Таким образом у вас получится примесь, разбитая на две части с этими «защитниками», которые гарантируют что только один из них будет исполнен.

LESS
.set-bg-color (@­text-color) when (lightness(@­text-color) >= 50%) { background: black; } .set-bg-color (@­text-color) when (lightness(@­text-color) < 50%) { background: #ccc; }
После использования вы получите подходящий фон:

LESS
.box-1 { color: #BADA55; .set-bg-color(#BADA55); }
Это очень просто, но суть, надеюсь, понятна. Вы можете делать вещи гораздо круче этого. LESS также позволяет делать ссылающейся на себя рекурсии, примеси которых могут вызывать самих себя с обновленными значениями.

LESS
.loop (@­index) when (@­index > 0) { .myclass { z-index: @­index; } // Call itself .loopingClass(@­index - 1); } // Stop loop .loopingClass (0) {} // Outputs stuff .loopingClass (10);

На этом логика/циклы в LESS и заканчиваются. SASS обладает актуальными логическими и циклическими операторами. if/then/else, цикл for, цикл while и цикл each. Без каких либо трюков, настоящее программирование. SASS является достаточно надежным языком, что делает возможным использование Compass.

Например, у Compass есть примесь background , которая является настолько мощной, что вы можете положить в нее все что захотите и в итоге получите именно то, что вам нужно. Картинки, градиенты и любая их комбинация, разделенная запятой - и вы получаете нужный результат (включая префиксы и все прочее).

Лаконичный кусок кода:

SCSS
.bam { @­include background(image-url("foo.png"), linear-gradient(top left, #333, #0c0), radial-gradient(#c00, #fff 100px)); }
Превращается этот код в монстра ниже (который, к сожалению, нужен в целях кроссбраузерности):

CSS
.bam { background: url("/foo.png"), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff)); background: url("/foo.png"), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px); }
Победитель: SASS

Победитель: LESS

@­extend концепция

Допустим вы создали класс с неким набором стилей. Затем вам понадобится создать еще один, который будет как предыдущий, но с некими дополнениями. LESS позволяет сделать это так:

LESS
.module-b { .module-a(); /* Copies everything from .module-a down here */ border: 1px solid red; }
По сути это обычный «include». Вы также можете использовать эту вставку и в SASS, но лучше это делать используя @­extend . @­extend не просто копирует стили из .module-a в .module-b (что производит к раздуванию файла), он меняет название селектора .module-a на .module-a, .module-b в скомпилированном CSS (что является более эффективным способом).

SCSS
.module-a { /* A bunch of stuff */ } .module-b { /* Some unique styling */ @­extend .module-a; }
Компилируется в:

CSS
.module-a, .module-b { /* A bunch of stuff */ } .module-b { /* Some unique styling */ }
Вы это видите? SASS переопределяет селекторы, и это более эффективный путь.

Победитель: SASS

Обработка переменных

LESS использует @, SASS использует $. Знак доллара не используется в CSS, чего нельзя сказать про @. Он используется для объявления @­keyframes или блоков @­media. Вы можете считать что использования того или другого спецсимвола это дело вкуса, но я думаю что SASS имеет здесь преимущество именно за счет того, что не путает базовые концепции.

SASS имеет странное свойство - если вы переопределите «глобальную» переменную «локальной», глобальная переменная примет ее значение. Немного странно.

SCSS
$color: black; .scoped { $color: white; color: $color; } .unscoped { // LESS = black (global) // SASS = white (overwritten by local) color: $color; }
Это трюк может быть полезным, но он совсем не интуитивен, особенно если вы пишете на Javascript.

Победитель: надо бросить монетку:)

Работа с правилами media

Почти каждый из нас, начиная работать с правилами @media , добавляет блоки с ними внизу главной страницы стилей. Это работает, но приводит к разъединению стилей, например:

CSS
.some-class { /* Default styling */ } /* Hundreds of lines of CSS */ @­media (max-width: 800px) { .some-class { /* Responsive styles */ } }
С помощью SASS или LESS вы можете объединить эти стили используя вложения.

SCSS
.some-class { /* Default styling */ @­media (max-width: 800px) { /* Responsive styles */ } }
«respond-to» - довольно таки крутая техника SASS (ознакомьтесь с кодом Chris Eppstein , Ben Schwarz , и Jeff Croft).

SCSS
=respond-to($name) @­if $name == small-screen @­media only screen and (min-width: 320px) @­content @­if $name == large-screen @­media only screen and (min-width: 800px) @­content
Дальше использовать их можно очень лаконично:

SCSS
.column width: 25% +respond-to(small-screen) width: 100%
Примечание: для использования этой техники вам будет нуже SASS 3.2, который пока находится в альфе, установить его можно командой gem install sass --pre . Я думаю что тут не должно быть сомнений в том, что это действительно полезная вещь в разработке.

Победитель: SASS

Метематика

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

LESS
div { width: 100px + 2em; // == 102px (weird) }
SASS даст вам четко и ясно понять что здесь спряталась ошибка:
Incompatible units: "em" and "px" . Конечно, это спорный вопрос что лучше - ошибка или неверное значение, но лично я - за первое. Особенно если вы отдаете предпочтение переменными вместо использования цифр, это очень сильно затрудняет их отслеживание.

SASS позволяет проводить математические операции с «неизвестными» единицами измерения, которые могут появиться до следующего обновления. LESS этого не позволяет. Есть еще более странные отличия, например, как SASS умножает числа с единицами измерения, но об этом не сегодня.

Победитель: SASS (с натяжкой)