Распечатать статью

SASS или LESS?

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

Очень краткий ответ: SASS.

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

Гораздо более длинный ответ: читайте дальше.

Гораздо более длинный ответ

Процесс обучения Ruby, командной строке и т.п.

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

Победитель: отсутствует.

Облегчение работы с CSS3

Используя любой из языков, вы можете написать свои собственные сочетания (mixins) для упрощения работы с вендорными префиксами. Ничья. Но вы ведь знаете, что вы не возвращаетесь и не обновляете префикисы во всех проектах? (Да, вы этого не делаете). Вы точно так же не будете обновлять mixin файлы (вероятно). А в SASS вы можете использовать Compass, и он будет обновлять сам себя, так что данная проблема решается. Да, вам нужно будет поддерживать актуальность локального приложения для препроцессинга, и иногда перекомпилировать его, но это элементарно и не требует затрат умственной энергии. Так что вот что получается: у SASS есть Compass, а у LESS его нет. Но мало того. Попытки создать работоспособный аналог Compass для LESS провалились, потому что сам язык LESS недостаточно мощный для правильной реализации этого. Про это еще поговорим.

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

Возможности языка: Логика/Циклы

У 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;
}

Так что когда будете это использовать, вы получите нужный цвет фона:

.box-1 {
  color: #BADA55;
  .set-bg-color(#BADA55);
}

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

.loop (@index) when (@index > 0) {
  .myclass {
    z-index: @index;
  }
  // самовызов
  .loopingClass(@index - 1);
}
// остановка итерации
.loopingClass (0) {}

// на выходе
.loopingClass (10);

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

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

И код краток и понятен:

.bam {
  @include background(
    image-url("foo.png"),
    linear-gradient(top left, #333, #0c0),
    radial-gradient(#c00, #fff 100px)
  );
}

А превращается он вот в такого монстра (который, к сожалению, необходим нам для максимально хорошей поддержки браузеров):

.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 более удобный в использовании сайт. Документация SASS вовсе не ужасная, она завершена и вы можете найти в ней всё, что нужно. Но в плане привлечения внимания людей LESS впереди. Я нисколько не сомневаюсь, что это играет далеко не последнюю роль в том, что на данный момент LESS пользуется большей популярностью. Впрочем, это может измениться.

Концепция @extend

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

.module-b {
   .module-a(); /* Копирует сюда всё из .module-a */
   border: 1px solid red;
}

По сути дела, это include. Миксин, работающий в обоих языках. Можете делать так и в SASS, но лучше воспользуйтесь @extend. С ним стили из .module-a не копируются просто в .module-b (что раздувает код), вместо этого селектор .module-a меняется в выходном CSS на .module-a, .module-b, что куда более эффективно.

.module-a {
   /* куча всего */
}
.module-b {
   /* какие-то уникальные стили */
   @extend .module-a;
}

Что компилируется в следующее:

.module-a, .module-b {
  /* куча всего */
}
.module-b {
  /* какие-то уникальные стили */
}

Видите? Он переписывает селекторы, что гораздо эффективнее.

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

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

LESS использует @, тогда как SASS — $. Знак доллара не имеет никакого значения в CSS, а вот «собака» – да. Используется для объявления @keyframes или блоков @media запросов. Вы можете сказать, что это несущественно и является делом личных предпочтений, но я думаю, что здесь SASS выигрывает, потому что не путает устоявшиеся концепции.

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

$color: black;
.scoped {
  $color: white;
  color: $color;
}
.unscoped {
  // LESS = black (глобальное значение)
  // SASS = white (перезаписано локальным)
  color: $color;
}

Я слышал, что это может быть полезным, но это не интуитивно, особенно если вы пишете на JavaScript.

Победитель: неизвестен

Работа с медиа-запросами

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

.some-class {
   /* Стили по умолчанию */
}

/* Сотни строк CSS */

@media (max-width: 800px) {
  .some-class {
    /* адаптивные стили */
  }
}

C SASS или LESS мы можем свести их в одном месте:

.some-class {
  /* Стили по умолчанию */
  @media (max-width: 800px) {
    /* Адаптивные стили */
  }
}

С SASS вы можете зайти еще дальше. Есть одна очень классная техника «respond-to» для именования и использования точек останова (смотрите код Криса Эпштайна (Chris Eppstein), Бэна Швартца (Ben Schwarz) и Джэффа Крофта (Jeff Croft))

=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

Вы можете использовать их коротко и семантично:

.column
    width: 25%
    +respond-to(small-screen)
      width: 100%

Примечание: для работы требуется SASS 3.2, который пока в альфа-версии, установить можно командой gem install sass --pre. По моему мнению, удобство работы с этим бесспорно.

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

Вычисления

Здесь по большей части всё одинаково, но есть некоторые странности с обработкой единиц измерения. Например, LESS считает, что первая используемая – это именно то, что вы хотите получить в результате, и будет игнорировать все последующие.

div {
   width: 100px + 2em; // == 102px (странно)
}

В SASS вы получите ясное сообщение об ошибке: несовместимые единицы «em» и «px«. Наверное, можно поспорить, что лучше: сообщение об ошибке или неправильный результат, но лично я предпочел бы первое. Особенно если вы имеете дело с переменными, значения которых сложнее проконтролировать.

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

Победитель: c небольшим отрывом SASS

Активность разработки

На время написания статьи…

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

Победитель: вероятно SASS

Источник:  css-live.ru
Вы можете оставить комментарий, или обратную ссылку на Ваш сайт.

Оставить комментарий

Похожие статьи