История изменений

2.2.x, в режиме scala

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

я просто использую 1 LESS-файл, в который импортом (встроенной возможностью LESS'а) добавляются все остальные стили. По сравнению с общим размером страницы, оверхед на дополнительные стили незначительный, плюс в продакшене это клиенту будет стоить 1 раз закэшировать файл, который вдобавок еще и gzip'нут, а вперспективе еще и можно положить под nginx.

А со стороны разработчика инклуды даже удобней, чем тыщи мелких css-файлов. Например, у меня первой строчкой подключается Twitter Bootstrap (его LESS-версия из гита, да), и потом IntelliJ IDEA прямо в редакторе кода делает автодополнение по бутстраповским стилям.

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

Первого по причине низкой квалификации верстальщика

можно объяснить как «LESS - это такой CSS, где есть переменные». Самая мастхэвная фича. Например, есть у тебя какой-нибудь прибитый к низу окна футер размером 60 пикселей, и относительно него считаются все остальные вертикальные размеры. И вот, размеры футера поменялись. Верстальщику ооочень геморно сидеть и по часу-больше вылавливать все вхождения чиселок, основанных на исходных «60 пикселях» - сами «60 пикселей» еще можно find and reaplce, а вот зависящие от них величины - жопа. Вместо того, чтобы тратить дни на безмозглую работу по find and replace, проще потратить полчаса на чтение документации LESSа, один раз определить размер футера переменной и радоваться.

2.2.x, в режиме scala

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

я просто использую 1 LESS-файл, в который инклудом (встроенной возможностью LESS'а) добавляются все остальные стили. По сравнению с общим размером страницы, оверхед на дополнительные стили незначительный, плюс в продакшене это клиенту будет стоить 1 раз закэшировать файл, который вдобавок еще и gzip'нут, а вперспективе еще и можно положить под nginx.

А со стороны разработчика инклуды даже удобней, чем тыщи мелких css-файлов. Например, у меня первой строчкой подключается Twitter Bootstrap (его LESS-версия из гита, да), и потом IntelliJ IDEA прямо в редакторе кода делает автодополнение по бутстраповским стилям.

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

Первого по причине низкой квалификации верстальщика

можно объяснить как «LESS - это такой CSS, где есть переменные». Самая мастхэвная фича. Например, есть у тебя какой-нибудь прибитый к низу окна футер размером 60 пикселей, и относительно него считаются все остальные вертикальные размеры. И вот, размеры футера поменялись. Верстальщику ооочень геморно сидеть и по часу-больше вылавливать все вхождения чиселок, основанных на исходных «60 пикселях» - сами «60 пикселей» еще можно find and reaplce, а вот зависящие от них величины - жопа. Вместо того, чтобы тратить дни на безмозглую работу по find and replace, проще потратить полчаса на чтение документации LESSа, один раз определить размер футера переменной и радоваться.