vermilion1 22 мая 2012 в 15:52

SASS против LESS

6 мин

186K

CSS * HTML * Веб-разработка *

Перевод

+38

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

TheShock 22 мая 2012 в 16:03

Вывод: автору больше нравится SASS, а не LESS.

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

Вы это видите? SASS переопределяет селекторы, и это более эффективный путь.
Победитель: SASS

Проблема в том, что SASS-подход сложнее отлаживать. В LESS ты знаешь, что если ты объявил это где-то здесь, то и в CSS оно будет где-то там же, а SASS будет разбросан по всему коду.

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

mixrin 22 мая 2012 в 16:33

SCSS ~ SASS. Те же яйца, вид снизу. SCSS обратно-совместим с CSS.

EvilShadow 22 мая 2012 в 16:38

SCSS тоже CSS-подобный синтаксис. Необязательно использовать отступы (sass), можно и скобки (scss). Более того, основным является как раз SCSS.

faiwer 22 мая 2012 в 16:52

Ну почему же.

— а чем SCSS не CSS-подобный синтаксис? Можно смело переименовывать css в scss, максимум выкинет ошибку синтаксиса аля «не поставлена ;»
— Используя SCSS я полюбил логику в CSS. Если её убрать, мне будет неудобно, т.к. привык к хорошему

По поводу строки кода — есть FireSass, который показывает строку кода и файл, но с ним много геморроя. Он у меня приводит к страшным тормозам в FireBug, и вообще флаг дебаг-строк добавляет к каждому правилу по 1 строке, и в итоге в старых IE css грузится на половину, если она большая.

С другой стороны, я не совсем понимаю, как организовать использование 50+ less файлов так, чтобы соблюдались номера строк? Это реально? Если нет, то встаёт проблема — или писать всё в одном файле (надеюсь никогда к этому не вернусь), или отдельно организовывать сборку CSS на живом сервере.

tibalt 23 мая 2012 в 10:57

Под SASS уже давно подразумевается SCSS, который совместим с CSS. Это в статье черным по белому. Автор провел прекрасное исследование, SASS действительно уже давно уделывает LESS. Compass не может быть переписан под LESS не потому, что его автору лень, а потому, что это сделать нельзя.

А генерация спрайтов в компассе — это вообще киллер-фича, избавляет от большой геморной рутины.

vasilyyaremchuk 22 мая 2012 в 16:15

Кажется внекоторых местах над кодом
нужно поставить SASS вместо SCSS?

tibalt 23 мая 2012 в 10:59

scss — развитие sass, совместимое с css. так-то.

DevMan 22 мая 2012 в 16:16

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

1. LESS можно вообще не компилировать отдельно.
2. Для LESS есть GUI-компиляторы.

Возможно такое же есть и для SASS (я не в курсе), но этот абзац мне показался странным (если не лишним).

morr 22 мая 2012 в 16:23

Вы когда-нибудь пробовали этот «не компилировать отдельно» использовать на продакшене в крупном проекте? Для презентаций оно выглядит красиво, но на практике — бесполезная игрушка.

morr 22 мая 2012 в 16:25

(я про компилировании стилей не на сервере, а в браузере)

DevMan 22 мая 2012 в 16:31

Пишу не холивара ради, а о том, что первый абзац сравнения ни о чем.

DevMan 22 мая 2012 в 16:30

Я не предлагаю этим пользоваться, только сказал, что такая возможность есть. Да и web состоит отнюдь не из одних крупных проектов с километровыми стилями.

А для компиляции LESS есть GUI, вся настройка которых сводится к указанию где брать LESS-файлы и куда класть CSS-файлы.

Kyuujitsu 23 мая 2012 в 05:20

К слову о GUI. Для SASS есть Scout

faiwer 23 мая 2012 в 05:37

Эх, жаль нет linux версии :(

Kyuujitsu 23 мая 2012 в 06:45

Да, в этом плане у LESS есть грандиозное преимущество в лице SimpLESS. С другой стороны, в консоли и так много времени проводишь, к чему нам лишние окна :)

faiwer 23 мая 2012 в 07:06

Ну у меня простой скрипт всё запускает ( $ css project_name ), но удобнее было бы, если бы был единый GUI менеджер со списком проектов, который бы умел прятаться в трей. А в консоли я провожу не так уж и много времени, больше сижу в редакторе и в браузерах :)

TheShock 22 мая 2012 в 16:34

Вы когда-нибудь пробовали этот «не компилировать отдельно» использовать на продакшене в крупном проекте?

Я сейчас так делаю. Единственное препятствие использовать такой код на продакшне — cross-origin policy, согласно которой less-файл не может лежать на отдельном домене. Но во время девелопмента у меня он компилируется рантайм, так что фича однозначно полезная

faiwer 22 мая 2012 в 16:56

Я тут, не так давно, приводил пример, когда обычный CSS код (правда очень много его, 100+ Кб) в less файле компилировался браузером Opera — 23 секунды, а в IE7 — 10 секунд. Просто пример. Понимаю, что ситуации бывают разные, однако не стоит переоценивать js-движки старых браузеров и оперы (хотя он вроде бы быстрый, странно).

LittleMeN 23 мая 2012 в 08:47

100+ Кб — сильно, что там такого можно было наворочить? это без URI вставок?

faiwer 23 мая 2012 в 15:30

Просто «легаси» скопилось много мусора, + довольно непростой сайт. Но css вполне реальная. Вот она. Разжирела уже до 200 Кб :)

mixrin 22 мая 2012 в 16:34

А это разве не selling-point LESS'а? То что можно eval'ить CSS-свойства как в старых IE через expressions? :)

Тогда вообще не вижу причин использовать LESS.

LittleMeN 23 мая 2012 в 08:45

Я вот честно скажу не пробовал — но подмывало много раз, ибо у меня .less + лоадер .js в разы меньше получается чем компилированный css(даже с жатием).

Увеличение нагрузки в браузере!? — сомнительно

Отдача 2 статических файлов less + js — мне кажется нименьшим злом по сравнению с «лишним» трафиком и нагрузкой на сервер при компиляции…

Есть у кого опыт нагруженных проектов БЕЗ предварительной компиляции less или sass с обработкой в браузере — чем плохо/хорошо — поделитесь?

vermilion1 23 мая 2012 в 08:51

Не обязательно компилировать каждый раз less-файл по запросу пользователя открыть страницу. Можно сделать это всего один раз и залить на сервер уже скомпилированный css

LittleMeN 23 мая 2012 в 09:22

Согласен, но я писал что у меня less+js в 2-3 раза меньше компиленного css, а явных препядствий для первого варианта я не вижу — может я чего-то не туда смотрю…

vermilion1 23 мая 2012 в 09:34

Зато вы два раза дергаете сервер:
1) less.js
2) style.less
В случае прекомпиляции и отдачи готового css из минусов вы получаете только пару килобайт лишнего траффика. Из плюсов — моментальное и корректное отображение стилей, меньшая нагрузка на сервер за счет уменьшения количества запросов к нему.
Ну, если вам так удобно, и время компиляции на клиенте очень маленькое — такой вариант тоже хорош

janekprostojanek 16 июн 2017 в 11:30

Сейчас бы в 2017 в профессиональной среде разработчиков без гуя не уметь обойтись…

VikentiyR 22 мая 2012 в 16:16

LESS выглядит всё-таки нагляднее.
Автор присудил побуду SASS за счёт Compass, но не стоит забывать, что нужно исходить из задач.
Я бы с удовольствием почитал бы статью, описывающую практическое применение Compass, плюсы и минусы, когда стоит использовать.

mixrin 22 мая 2012 в 16:37

Берёшь и используешь. Ну или и не используешь.

Плюсы? Забыть про набивание префиксов к свойствам, и необходимость запоминать по три варианта синтаксиса для одного свойства (привет градиенты). Ну или просто километровые строки (привет трансформации).

Минусы? Ну надо поставить гем. Возможно что-то настроить, в последний раз вроде изкаропки всё заводилось.

creage 22 мая 2012 в 18:44

Минусы? Ну надо поставить гем. Возможно что-то настроить, в последний раз вроде изкаропки всё заводилось.

Я купил тулзу за $10, которая следит за моими папками, и сама генерит все на лету. Не надо ничего ставить, все работает из коробки. Никаких гемов, Ruby и т.п.

philpirj 22 мая 2012 в 19:41

Сам Compass тоже умеет всё из коробки. И не нужно .app. А можно и бесплатно.

akzhan 22 мая 2012 в 20:27

less -watch или куча бесплатных утилит типа winless.

creage 22 мая 2012 в 18:38

Compass умеет делать спрайты из моей папки иконок — это просто неимоверно удобно. Добавить новую иконку? Изменить имеющуюся? Один клик!

morr 22 мая 2012 в 16:21

На минувшем Railsconf 2012 был отдельный доклад про sass, где анонсировали 3 фичи над которыми сейчас ведётся работа, и которые появятся в следующем релизе:
1. libsass — написанный на C компилятор sass в css, работающий быстрее на порядки нынешнего скрипта на руби. Для крупных проектов это очень существенно — большие объёмы стилей при деплое компилируются ну очень долго(полминуты и дольше). Так же это позволит написать биндинги для libsass к другим языкам, что означает более простое встраивание sass во фрейморки питона/ноды/дотнета/пхп.
2. Mixin Content — аналог yield в sass, позволяющий передавать блоки кода в миксины.
3. Placeholder Selectors — наследование свойств от произвольных селекторов (сейчас отнаследовать можно только от конкретного css класса).

А ещё докладчик постебался, что в less много багов, и что их не фиксят :)

faiwer 22 мая 2012 в 16:58

1. Хочу, хочу, хочу. Скорость текущего парсера, оставляет желать лучшего, на моей, не самой производительной, машине.
2. Можно чуть подробнее?

morr 22 мая 2012 в 17:03

с 12:25 на www.youtube.com/watch?v=MFwId6xSh2o

НЛО прилетело и опубликовало эту надпись здесь

rushman 23 мая 2012 в 18:12

Python-биндинги для libsass. Эксклюзивно для Хабра habrahabr.ru/post/144419/

Igorbek 11 июл 2012 в 02:40

а я сделал для .Net: habrahabr.ru/post/147567/

НЛО прилетело и опубликовало эту надпись здесь

smashercosmo 22 мая 2012 в 16:57

SASS не поддерживает на данный момент такую вот штуку

.some-parent-class {
    &__some-modificator {
        color: red;
    }
}

в LESS это все компилируется в

.some-parent-class__some-modificator {
    color: red;
}

Полезно для БЭМа.
Хотя в версии 3.2 вроде как обещают запилить.

mixrin 22 мая 2012 в 21:55

Для ховеров и прочего работает.

mixrin 22 мая 2012 в 21:56

sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#referencing_parent_selectors_

reiser 23 мая 2012 в 07:11

Как это не поддерживает?
Вполне поддерживает, причём точно также:

&:hover

&:first-child

&.another_class

faiwer 23 мая 2012 в 08:26

Если я правильно понял smashercosmo, то он имеет ввиду не доп.класс, а склеить одно название класса по кускам, используя вложенность.

reiser 23 мая 2012 в 08:58

Да, вероятно вы правы.
Видимо мне подобное никогда не требовалось, раз в голову не пришло.

smashercosmo 23 мая 2012 в 11:58

Я ж сказал, что это полезно, если верстаешь по БЭМу. У них же все имена классов формируются по префиксному принципу.

SeVit 31 мая 2013 в 11:09

&_
&-

в 3.2 так и не запилили, обещают в 3.3

student_ivan 22 мая 2012 в 18:37

По мне дак удобнее запустить фоновый преобразователь less в css, писать в less и не парится

Smartfon 22 мая 2012 в 19:04

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

Выигрывает по всем параметрам, а кроме того, написан на Node.JS, что избавляет от pain in ass с установкой последней беты Ruby через rvm.

XimikS 22 мая 2012 в 19:39

Да, для ноды очень удобная штука, в сочетании с jade вообще радость питониста. Есть врапперы под руби и питон, сам не проверял.
https://github.com/lucasmazza/ruby-stylus
https://github.com/lusentis/django-stylus

НЛО прилетело и опубликовало эту надпись здесь

pro100tak 23 мая 2012 в 00:14

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

Пипец как странно — лезть в глобальный контекст при переопределении локального. Яваскриптеры меня поймут. Тут как раз SASS проиграл.

faiwer 23 мая 2012 в 04:17

Я полагаю дело в том, что переменная не переопределяется в другой «области видимости», а в том, что ей просто задаётся другое значение. По мне так, вполне логично. Ведь синтаксис то 1 и тот же.

monolithed 23 мая 2012 в 05:03

Насколько я понимаю, CSS-фреймворки используются для того чтобы:

1. Использовать вложенные инструкции
2. Минифицировать результирующий код (пробелы, табуляция, rgb -> hex -> short hex triplet)
3. Генерация CSS правил серверным кодом
4. Дополнить кроссбраузерными CSS3 правилами (как-правило опционально и не везде есть)

Наличие остальных фич уже сомнительно…

Для первых 3-х пунктов у меня есть экстремально небольшая либа (пара десятков строк), которая делает следующее:

object =
  html:
    background: 'red'
    body:
      color: 'rgb(255, 255, 255)'
      'div > p':
        color: 'green'
        border: '#000008'
  input :
    border : '1px solid #110011'

Будет транслировано в валидный CSS-код:

html {
    background: red;
}

html body {
    color: #FFF;
}

html body div > p {
    color: green;
    border: #000008;
}

input {
    border: #101;
}

Чтобы перевести поток в файл не нужно никаких танцев с бубном:

file = fs.createWriteStream 'file.css',
    flags: 'a'
    encoding: 'utf-8'
    mode: 0666

file.on 'error', (error) ->
    console.error error

file.write to.toCSS object

file.end ->
    console.log to.toCSS object

При этом имеется 3 реализации (CoffeeScript, JavaScript, Python), а это значит что достаточно наличия Node+CoffeeScript или Python.

PS: в JavaScript и Python версии фигурные скобки обязательны, в CoffeeScript опциональны

morr 23 мая 2012 в 07:09

Сомнительные потому, что ваша библиотека, не умеет их?
Постоянно использую:
1. Миксины — блоки стилей, вставляющиеся внутрь любого селектора. Через них же реализованы кроссбраузерные css3 правила. Миксины для DRY — на порядок сокращают повторения в коде.
2. Переменные. Обычно для задания цветов и отступов. DRY.
3. Арифметика — как правило сложение/вычитание для переменных с отступами.
4. Загрузка других scss файлов внутрь текущего, аналог import/include из других языков программирования. Без этого как минимум пукты 1 и 2 не будут работать.

А синтаксис вашей либы — вылитый sass, только с синтаксическим мусором: «object =», кавычки после двоеточия, двоеточие после селектора.

monolithed 23 мая 2012 в 07:39

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

html:
   background: ['#111', '#222', '#333', '#444', '#555', '#666', '#777'][today]
   color:
       if 1 > 2
         'red'
       else
         'green'

А синтаксис вашей либы — вылитый sass

Как я упомянул выше можно использовать фигурные скобки:

html: {
   background:  {
      ['#111', '#222', '#333', '#444', '#555', '#666', '#777'][today]
   },
   color: {
       if 1 > 2
         'red'
       else
         'green'
   }
}

только с синтаксическим мусором: «object =

Если писать стили в отдельном файле, то название объекта писать необязательно!

Кавычки после двоеточия, двоеточие после селектора.

Меня это тоже немного смущает, но зато такой код может работать даже на клиенте и без тормозов, т.к. ничего не парсится!

Иными словами, словами все тоже самое только нет фич для CSS3, а добавить эту возможность очень просто (мне пока это не особо нужно).

tibalt 23 мая 2012 в 11:09

здоровенный css-файл с продакшена я могу переименовать в scss, а потом уже постепенно рефакторить его. css-совместимый синтаксис — сильная сторона scss (как и less)

Dart 23 мая 2012 в 06:55

Подскажите, а как заставить NodeJS компилятор LESS-файлов исправлять относительные пути (фоновые картинки, шрифты), так что бы они были правильными относительно расположения скомпилированного файла? JavaScript компилятор правильно переопределяет эти пути, а NodeJS оставляет их без изменения. По моему это достаточно существенный минус у родного компилятора LESS.

reiser 23 мая 2012 в 07:18

Ещё один довод в пользу SASS/SCSS — есть возможность выбора синтаксиса.
Именно SASS мне нравится куда больше SCSS, код становится чище и понятнее :)

Inq 23 мая 2012 в 07:49

ИМХО, инструмент надо выбирать в соответствии с задачей. Не сталкивался еще ни разу с проектом, где вместо LESS потребовался бы SASS с его несколько большими возможностями.
В связи с этим нет инструмента лучше или хуже. Есть тот, который подходит под задачи, и тот, который по каким-то причинам не подходит (слишком просто или слишком избыточен).

bashmish 23 мая 2012 в 07:56

Вы не рассмотрели тот момент, что у LESS есть компилятор на стороне браузера — LESS.js

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

vermilion1 23 мая 2012 в 08:01

Это перевод :)
На самом деле компилятор на стороне браузера вещь хорошая, но только для девелопмента.
Для продакшина такое время компиляции недопустимо.

НЛО прилетело и опубликовало эту надпись здесь

Inq 23 мая 2012 в 08:02

Это удобно на стадии разработки и отладки, не более.
Ну или когда стили LESS не километровые, но сам так не делал.

Theo_from_Sed 12 фев 2013 в 16:35

Есть аналог sass.js на гитхабе.

loingrim 23 мая 2012 в 10:09

Вот сейчас собираюсь попробовать SASS, и всё сомневаюсь: с одной стороны — куча возможностей, генерация спрайтов, примеси и прочее, а с другой — мне он кажется каким-то неизящным. Дело привычки, конечно…

Вот что меня действительно беспокоит, так это как отлаживать и изменять верстку. Может я ошибаюсь, но кажется, что примеси будут сложны в поддержке, потому как сразу не видно, куда эти изменения приминяются. Кто работал, скажите, как вы отлаживаете верстку?

Еще, ребота с вложениями очень смахивает на прекрасный инструмент, чтобы выстрелить себе в ногу :)

tibalt 23 мая 2012 в 11:11

есть firesass для фаербага. надо только отладочный режим подетальней включить, чтобы в css-файлах писалось из какой строчки scss генерировался данный кусок.

morr 23 мая 2012 в 11:37

> Кто работал, скажите, как вы отлаживаете верстку?
Многие действия провожу в веб инспекторе хрома, когда надо что-то подтюнить, то сначала правлю в инспекторе, сразу же наблюдая результат, а потом копирую измения в файл стилей.
При таком методе нет никаких отличий между css и scss.

В девелопмент режиме, без склейки стилей в один файл, содержимое каталога с scss файлами соотностится почти 1 к 1 c содержимым каталога со скомпилированными стилями (если не увлеваться инклудом одних файлов стилей в другие).
И в веб-инспекторе вы видите, какие наложены стили, по какому селектору, и из какого файла оно пришло. Соответственно правите нужный селектор в нужном файле.

Если же делать без инспектора, просто вслепую набирая в файле стили и проверяя затем в броузере, то опять же никакой разницы с чистым css — сохранили файл, альт-таб, ф5, видим результат.

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

loingrim 23 мая 2012 в 13:42

Вот я тоже сначала в испекторе подгоняю.

А как Вы меняете xчто-то в миксинах? Или на миксины разбиваете в самом конце?

Просто я обычно пишу селекторы через запятую. В таком случае когда в общем стиле что-то меняешь, то сразу видишь, где что поменяется, а миксины придется искать. И вот этот момент мне представляется потенциально неудобным.

Соответственно меня интересует, как другие справляются с такими задачами. Может я прсто придумываю себе проблему?..

morr 23 мая 2012 в 14:04

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

@ mixin image-selectable-decor {
  @ include transition(background-color, 0.2s); <- миксин для кроссброузерного css3 из compass фреймворка

  background-color: $default-image-background;
  &:hover {
    background-color: $default-image-hover-background;
  }
  &:active {
    background-color: $default-image-active-background;
  }
}

Разные миксины с кодом оформления дефолтных заголовков, ссылок, каких-нибудь блоков, переменные с несколькими осными цветами, на которых дизайн сайта построен и подобное.

Искать ничего не придётся, потому что в коде у вас будет что-то такое:

.news, .articles {
  @ include default-info-block;
  /* какое-то свойство из default-info-block тут может быть переопределено */
  font-size: 13px;
}
/* а какое-то свойство лишь для одного класса изменено */
.news {
  color: red;
}

Вы сразу видите, что там из миксина всё берётся, а мест, где может быть определён нужный миксин, у вас будет всего 1-2.

nickostyle 26 мая 2012 в 19:30

Объясните пожалуйста на элементарном примере, зачем нужен метаязык? Просто мне стало любопытно, начал вникать, но так особо преимуществ не нашел. Ну где то можно объявить переменную, и поменять цвет, к примеру, во всех элементах где он используется, поправив только одну строчку. Плюс. А что еще?

unclechu 4 мая 2014 в 15:19

По поводу extend, — в Less тоже есть extend.
См. доки: lesscss.org/features/#extend-feature
Пост мягко-говоря староват, и несколько не актуален, так что на момент написания статьи наверняка extend-а ещё не было.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий