Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
И правда любопытный сервис, wrangl.com, спасибо!
Где то пол года назад попробовал LESS, и влюбился в него, теперь верстаю только на нем.
SASS тоже может использовать классы как mixin:
@extend .class_name
Слышал, видел, но сам особо с ними не работал, хотя некоторые друзья до сих пор на них работают. Наверно потому что не очень люблю подобные вещи, и особо их не кто и не навязывал.
Но как то раз мне очень красочно расписали «LESS + Twitter Bootstrap», и уговорили попробовать нарисовать и сверстать 1 проект с их использованием. Все оказалось на столько просто и удобно…
Но как то раз мне очень красочно расписали «LESS + Twitter Bootstrap», и уговорили попробовать нарисовать и сверстать 1 проект с их использованием. Все оказалось на столько просто и удобно…
А почему ничего не сказано о LESS App ( incident57.com/less/ ), с помощью которой на Mac OS можно генерировать CSS из LESS, и использовать стили уже без js (т.е. как стандартный файл стилей)?
Использую SCSS как более функциональный, но LESS, действительно, очень нравится из-за возможности непосредственной прикрутки к сайту… Вообще только сейчас четта посетила мысля, которая раньше не приходила в голову. А почему бы не миксить оные решения. Т.е. определенную тяжелую, требующую повышенной функциональности, описываем на SCSS, а часть которая требует компиляции на стороне клиента — через LESS. Получится довольно таки интересная связка.
Компилятор less есть даже на php, правда он не все фичи поддерживает.
Хотя mixin мне кажутся интересным решением, но мне всегда почему-то казалось, что это как-то идеологически неправильно. Использование множественных классов и более стройной иерархии выглядит более правильным методом. Хотя могу и ошибаться.
Но переменные, вложенные селекторы и свойства, возможности не писать префиксы для всех вендоров — это большие плюсы, заметно облегчает читаемость и поддержку кода.
А использование less.js выглядит очень странным — в случае отключенного/заблокированного js отвалятся и стили. Разумно разве что на сильно аяксовых приложениях, где наличие js — требование системы.
Хотя mixin мне кажутся интересным решением, но мне всегда почему-то казалось, что это как-то идеологически неправильно. Использование множественных классов и более стройной иерархии выглядит более правильным методом. Хотя могу и ошибаться.
Но переменные, вложенные селекторы и свойства, возможности не писать префиксы для всех вендоров — это большие плюсы, заметно облегчает читаемость и поддержку кода.
А использование less.js выглядит очень странным — в случае отключенного/заблокированного js отвалятся и стили. Разумно разве что на сильно аяксовых приложениях, где наличие js — требование системы.
Можно глупый вопрос? А зачем всё это? Чем вам обычный CSS-то не угодил?
Однажды подсев на SCSS, я уже не могу от него отказаться без каких-либо радикальных причин. Мой CSS-код стал гораздо более маштабируемым, легко изменяемым, структурированным. А самое главное резко возросла скорость его написания (за счёт mixin-ов, переменных и вложенности селекторов) и он стал мне приятен ;) Обычный CSS код мне никогда не нравился, из-за неудобного синтаксиса.
Пара вопросов к вам, как к уже частично разобравшемуся в обоих технологиях человеку:
1. есть ли в Less циклы, массивы? как то раз пришлось писать много однотипного css-кода, который было сложно оптимизировать вне css. Что-то вроде @for ( 'link', 'upload', 'media' ) as $name {...}. В документации к SCSS я не нашёл такой возможности.
2. насколько сильно тормозит компиляция на лету путём less.js больших CSS файлов? Я less не пробовал, но мне кажется, что на крупных проектах это будут существенные тормоза. Во всяком случае SCSS у меня компилируется около полу-секунды, не меньше.
3. Ещё интересует вопрос вложенных less файлов. В случае SCSS я имею целую кучу .scss файлов в удобном для меня расположении (модули, js-модули, баз.движок и пр.). Если я правильно понимаю философию Less, то мне придётся заставлять пользователя грузить все эти файлы, либо писать весь код в 1-ом или 2-ух файлах по старинке. Это так?
4. Ну и последний вопрос — насколько удобно устроена компиляция на сервере путём использования ruby? Это готовое приложение которое само в real-time режиме отслеживает все изменения в файлах и компилирует по мере необходимости (как в sass)? Или это что-то вроде API для написания своего кода на ruby?
1. есть ли в Less циклы, массивы? как то раз пришлось писать много однотипного css-кода, который было сложно оптимизировать вне css. Что-то вроде @for ( 'link', 'upload', 'media' ) as $name {...}. В документации к SCSS я не нашёл такой возможности.
2. насколько сильно тормозит компиляция на лету путём less.js больших CSS файлов? Я less не пробовал, но мне кажется, что на крупных проектах это будут существенные тормоза. Во всяком случае SCSS у меня компилируется около полу-секунды, не меньше.
3. Ещё интересует вопрос вложенных less файлов. В случае SCSS я имею целую кучу .scss файлов в удобном для меня расположении (модули, js-модули, баз.движок и пр.). Если я правильно понимаю философию Less, то мне придётся заставлять пользователя грузить все эти файлы, либо писать весь код в 1-ом или 2-ух файлах по старинке. Это так?
4. Ну и последний вопрос — насколько удобно устроена компиляция на сервере путём использования ruby? Это готовое приложение которое само в real-time режиме отслеживает все изменения в файлах и компилирует по мере необходимости (как в sass)? Или это что-то вроде API для написания своего кода на ruby?
1. Циклов нет — я об этом написвл.
2. Насколько тормозит на крупных проектам самому интересно — более 10к less-файлы не пробовал, а они не тормозят.
3. Со вложенностью все также как и в scss — @import
4. Я даже незнаю как оно устроено — просто вместо sass-rails подключил less-rails в Gemfile и все.
2. Насколько тормозит на крупных проектам самому интересно — более 10к less-файлы не пробовал, а они не тормозят.
3. Со вложенностью все также как и в scss — @import
4. Я даже незнаю как оно устроено — просто вместо sass-rails подключил less-rails в Gemfile и все.
2. Жаль, 10КБ маловато будет. Интересно как он себя поведёт при 70-170КБ
3. Пожалуй это серьёзный минус компиляции «на лету»
Исходя из вашей статьи, нисколько не жалею, что выбирая между LESS и SCSS, я выбрал SCSS.
Забыл к пред.комментарию дописать, что я использую SCSS вместо SASS по 2 соображениям:
1. он почти как CSS, проще адаптироваться команде
2. можно без изменений использовать обычный CSS-код (конечно, никто не мешает совмещать оба стиля, но каша же получится).
3. Пожалуй это серьёзный минус компиляции «на лету»
Исходя из вашей статьи, нисколько не жалею, что выбирая между LESS и SCSS, я выбрал SCSS.
Забыл к пред.комментарию дописать, что я использую SCSS вместо SASS по 2 соображениям:
1. он почти как CSS, проще адаптироваться команде
2. можно без изменений использовать обычный CSS-код (конечно, никто не мешает совмещать оба стиля, но каша же получится).
1.25 сек на быстром ПК в самом быстром браузере, по вашему, это достойный результат? Представляю сколько будет грузится такой файл в IE7 на слабой машине. Или как шустро он взлетит на планшете. Причём, если я правильно понял технологию, компилироваться файл будет для каждой страницы.
6 лет, ИМХО, это относительно новый :) Не все же геймеры, да 3д дизайнеры. Итого, в случае Less, мы имеем:
1. Существенные тормоза при загрузке страницы, если CSS файл большой. Причём тормоза никуда не исчезают при последующих загрузках страницы.
2. Сумасшедшие тормоза в IE8 (а в IE6-7?).
3. Необходимость содержать весь less-css код в 1 или нескольких файлах, что крайне неудобно для средне-крупных проектов.
4. Меньше возможностей, чем у SCSS. Нет даже вложенности селекторов (ИМХО, самый главный минус CSS). Ну а про отсутствие логики…
Взамен верстальщик получает:
1. Можно не запускать в фоновом режиме компилятор
2. Можно писать так: @height: `document.body.clientHeight`;
Возникает резонный вопрос — зачем нужен Less? Ну а если рассматривать только серверную компиляцию, то особенно сильно встаёт пункт 4 — зачем использовать заведомо более слабый инструмент?
1. Существенные тормоза при загрузке страницы, если CSS файл большой. Причём тормоза никуда не исчезают при последующих загрузках страницы.
2. Сумасшедшие тормоза в IE8 (а в IE6-7?).
3. Необходимость содержать весь less-css код в 1 или нескольких файлах, что крайне неудобно для средне-крупных проектов.
4. Меньше возможностей, чем у SCSS. Нет даже вложенности селекторов (ИМХО, самый главный минус CSS). Ну а про отсутствие логики…
Взамен верстальщик получает:
1. Можно не запускать в фоновом режиме компилятор
2. Можно писать так: @height: `document.body.clientHeight`;
Возникает резонный вопрос — зачем нужен Less? Ну а если рассматривать только серверную компиляцию, то особенно сильно встаёт пункт 4 — зачем использовать заведомо более слабый инструмент?
1) Я взял живой 170 Кбайтный css-код. Результат:
1. Chrome — 0.4-0.6 сек
2. Firefox — 0.5-0.8 сек
3. IE 7 — 10+ сек
4. Opera 12 — 24-27 сек
2) Зачем вы сюда всё время приплетаете анимацию и загрузку картинкок. Less от этого меньше тормозить не будет. К тому же такие вещи, как анимация, вполне можно отключить для старых браузеров
3) Собственно, а что не так? Каким образом клиентский-javascript может получить css-код из 20 файлов, не загружая 20 файлов? Или вы предлагаете шаманить на сервере?
4) Сабж + этой
По поводу вашего ответа на «верстальщик получает» — в чём преимущество перед SCSS(SASS)? Ещё просьба сбавить тон…
1. Chrome — 0.4-0.6 сек
2. Firefox — 0.5-0.8 сек
3. IE 7 — 10+ сек
4. Opera 12 — 24-27 сек
2) Зачем вы сюда всё время приплетаете анимацию и загрузку картинкок. Less от этого меньше тормозить не будет. К тому же такие вещи, как анимация, вполне можно отключить для старых браузеров
3) Собственно, а что не так? Каким образом клиентский-javascript может получить css-код из 20 файлов, не загружая 20 файлов? Или вы предлагаете шаманить на сервере?
4) Сабж + этой
По поводу вашего ответа на «верстальщик получает» — в чём преимущество перед SCSS(SASS)? Ещё просьба сбавить тон…
IE старый потому что под него верстать надо. Что вы подразумеваете под боевым вариантом? Тот самый 11 КБ файл? Вот 170 КБ файл, пробуйте. Самый что ни на есть боевой.
По поводу всего остального — facepalm.jpg. Если есть желание — можем продолжить «дискуссию» в личке.
По поводу всего остального — facepalm.jpg. Если есть желание — можем продолжить «дискуссию» в личке.
> реализации цветовых схем на стороне клиента на основе времени суток/времени года/сессионной куки
Если цветовых схем не много, то, ИМХО, проще реализовать доп.классом и цветной математикой. В SCSS для этого есть циклы.
> Или локализация свойства content для псевдоэлементов.
Не так давно это обсуждалось на хабре. Да, на лету будет несколько проще, но, ИМХО, это весьма сомнительная затея.
Касательно вашего трюка — непонятно откуда берутся @sidebarLeftWidth и пр.? Если это просто переменные, то чем хуже вариант:
Или я вас не правильно понял?
Если цветовых схем не много, то, ИМХО, проще реализовать доп.классом и цветной математикой. В SCSS для этого есть циклы.
> Или локализация свойства content для псевдоэлементов.
Не так давно это обсуждалось на хабре. Да, на лету будет несколько проще, но, ИМХО, это весьма сомнительная затея.
Касательно вашего трюка — непонятно откуда берутся @sidebarLeftWidth и пр.? Если это просто переменные, то чем хуже вариант:
#container #center {
float: left;
width; 100%;
body &.sidebar-first { margin-left: $sidebarLeftWidth; }
...
}
Или я вас не правильно понял?
Т.е. вы имеете ввиду это:
Этот метод очень удобный и я активно его эксплуатирую везде где только можно. Самое простое — добавлять к тегу body класс с именем браузера, с именем браузера и целочисленной частью версии.
// пример
#some {
color: orange;
body.my_super_duper_class & { color: red; }
}
=>
#some { color: orange; }
body.my_super_duper_class #some { color red; }
Этот метод очень удобный и я активно его эксплуатирую везде где только можно. Самое простое — добавлять к тегу body класс с именем браузера, с именем браузера и целочисленной частью версии.
В смысле избыточна? 1 символ избыточен? :) Я полагаю, что его отсутствие — алогично. Совсем не обязательно, что в префиксе будет указаны теги html или body.
К тому же, исходя из этой статьи в less нельзя записать:
С момента написания этой статьи такая возможность появилась? В SCSS символ & обозначает текущий селектор. А вот в вашем примере я долго не мог понять, каким образом less определит, что префикс это префикс, а не суффикс…
К тому же, исходя из этой статьи в less нельзя записать:
a {
color: red;
&:hover { color: orange; }
}С момента написания этой статьи такая возможность появилась? В SCSS символ & обозначает текущий селектор. А вот в вашем примере я долго не мог понять, каким образом less определит, что префикс это префикс, а не суффикс…
Меня вот тоже интересует вопрос производительности.
Есть ли у кого примеры реальных проектов написанных с использованием таких технологиях?
Есть ли у кого примеры реальных проектов написанных с использованием таких технологиях?
1. Sass так умеет
@each $name in link, upload, media {
.#{$name} {
...
}
}
По сути оба проекта делают одно и тоже и фундаментальных различий не имеют.
Самый главный аргумент в сторону LESS — парсинг стилей яваскриптом непосредственно в броузере пользователя, имхо вещь весьма сомнительная — ведь мало кто захочет замедлять скорость отклика страницы пользователя ради вещей, которые можно получить и другим путём.
А вот больший функционал SASS аргумент более весомый, и пусть что-то из этого функционала вам сейчас не нужно, но потенциально вы сможете с SASS сделать больше. Плюс на выбор синтаксис со скобками или синтаксис с отступами — очень серьёзный довод для тех, кто используют питон или пишут шаблоны на HAML/Slim.
И самый последний аргумент — Rails 3.1 с SASS по дефолту. Имхо это для многих не определивщихся, или только желающих попробовать, положит конец эпопеи LESS vs SASS.
Самый главный аргумент в сторону LESS — парсинг стилей яваскриптом непосредственно в броузере пользователя, имхо вещь весьма сомнительная — ведь мало кто захочет замедлять скорость отклика страницы пользователя ради вещей, которые можно получить и другим путём.
А вот больший функционал SASS аргумент более весомый, и пусть что-то из этого функционала вам сейчас не нужно, но потенциально вы сможете с SASS сделать больше. Плюс на выбор синтаксис со скобками или синтаксис с отступами — очень серьёзный довод для тех, кто используют питон или пишут шаблоны на HAML/Slim.
И самый последний аргумент — Rails 3.1 с SASS по дефолту. Имхо это для многих не определивщихся, или только желающих попробовать, положит конец эпопеи LESS vs SASS.
Абсолютно верно. Кроме одного момента — возможности предоставляемые рендерингом на стороне клиента нельзя получить другим путем, тот-же SASS никак не сможет учитывать в стилях размер видимой области. Нужно ли вам это в проекте это уже другой вопрос.
Насчет замедления отклика — интересно было бы узнать насколько она реально замедляется.
Насчет замедления отклика — интересно было бы узнать насколько она реально замедляется.
SASS + Сompass наше все.
Есть на компасе кстати сборка html5 boilerplate
Есть на компасе кстати сборка html5 boilerplate
Только Stylus! learnboost.github.com/stylus/
Есть ещё сравнение LESS и SASS от разработчиков Compass: gist.github.com/674726
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткий обзор отличий LESS от SASS