Какой css-фреймворк можно наследовать тихим классом в scss из коробки?

Question

[Никита Кит]

Бутстрап не предлагать!

Ребят, хочу найти такой фреймворк, который по сути для компилятора scss будет компонентным, и его компоненты будут наследоваться не через точку, а через процент.
Когда пользовался бутстрапом, все его классы с точкой через import после компиляции падали в main.css. Выкачивать и заменять все точки в классе на процент муторно, но это единственный вариант избежать наследования всего фреймворка и сократить стили во много раз.
Недавно наткнулся на blazecss. Он мне понравился куда больше бутстрапа (составлен по БЭМ, классы компонентов не такие навязчивые как в бутстрапе, сетка более гибкая), но в scss всё равно везде стандартные классы (оно и понятно - стандартный способ наследования стилей через класс в разметке). Есть ли фреймворк с версией наследования через тихие классы? (%)

Comments

[Serj-One]

Что мешает использовать миксины? Очень сомневаюсь в целесообразности использования тихих классов в фреймворке.

[Никита Кит]

Serj-One: миксины медленно компилятся и разводят copy paste в css. Несмотря на don't repeat yourself разрабы продолжают использовать миксины. За что им будет выделен отдельный котёл в аду.

[Serj-One]

Никита Кит:
1) Миксины сами по себе куда мощней и функциональней, поэтому разница в скорости вполне простительна, к тому же, она не так велика.
2) Сколько бы котлов мне не пророчили, между этими двумя способами

.block_1{
	color: red;
	background: #fff;	
}
.block_2{
	color: red;
	background: #000;	
}

.block_1, .block_2{
	color: red;
}
.block_1{
	background: #fff;	
}
.block_2{
	background: #000;	
}

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

[Никита Кит]

Serj-One: "Миксины сами по себе куда мощней и функциональней" - поясни-ка конструктивно, почему include лучше extend? Чем копипаста лучше наследования?

[Serj-One]

Никита Кит:
Ответ уже дан - "я всегда выберу первый, как наиболее поддерживаемый". В любом долгоживущем проекте нужно учитывать читаемость конечного кода.
extend группирует совершенно несвязанные между собой элементы по незначительной общей группе свойств. Проще говоря, генерирует кашу в результирующем css. Разбрасывание свойств элемента по всему файлу ради сомнительной экономии пары килобайт сложно назвать хорошей идеей. Миксины же позволяют получить на выходе чётко структурированный код.

Конечно, нужно понимать контекст использования. Допустим, для кнопок и их вариантов вполне возможно использовать и extend (хотя я предпочту БЭМ подход с основным классом и модификаторами, без наследования). Для структурных элементов использование extend уже дикость.

[Никита Кит]

Serj-One: "extend группирует совершенно несвязанные между собой элементы по незначительной общей группе свойств".
extend ничего не группирует. Группируешь ты. Ты просто описал, что не умеешь ими пользоваться - вот и всё. Если котелок варит, в extend запутаться не выйдет. Если ты отделяешь стили модулей, наследуемые материалы и css фреймворк по разным каталогам проекта, то запутаться сложно.
1) extend компилируется быстрее.
2) extend добавляет класс к свойству, а не копипастит свойства в класс
3) extend позволяет использовать модификаторы, include нет.

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

[Serj-One]

Никита Кит:
>> "extend ничего не группирует. Группируешь ты. Ты просто описал, что не умеешь ими пользоваться - вот и всё. "
Пример я привёл выше. В чём же я не прав? Твой результат как-то отличается от моего примера?

>> "2) extend добавляет класс к свойству, а не копипастит свойства в класс"
Ну так это я и ставлю главным минусом, а ты начинаешь необоснованно агриться, что я чего-то не понимаю (см. п. 1).

>> "3) extend позволяет использовать модификаторы, include нет. "
Каким боком здесь модификаторы? Модификатор вообще не должен наследовать свойства основного класса. Но если нужно включить какой-то шаблон, это позволяют сделать оба варианта.

>> "Так что объективно, ты не прав."
Ты перепутал. Твоё мнение - это "субъективно".

>> "На форумах уже целый вагон статей, в которых все советуют отказываться от миксинов".
На любую тему, подразумевающую выбор, есть вагон статей. Пока не видел ни одного разумного довода в пользу extend относительно миксинов, вижу только "бысрей, копипаста, азаза", естественно, без аргументов. Хотя, строго говоря, сравнивать миксины и тихие классы некорректно априори.

[Никита Кит]

Serj-One: ну короче любовь к наследованию через extend и минификации css тебе не привить. блин, я пытался как мог))))

[Serj-One]

Никита Кит: Минификация должна иметь разумные пределы. Да и в целом, поддерживаемость и чёткое структурирование кода всегда важней оптимизации (которая, впрочем, в обсуждаемом случае настолько незначительна, что ей можно полностью пренебречь).

[Никита Кит]

Serj-One: а зачем в скомпилированном css, где так или иначе страшно, поддерживаемость и структурирование? В понимании человека поддерживаемость и структурирование должны быть в исходниках вёрстки. А в понимании движка браузера - минификация и оптимизация - главное и основное. И неважно какой кошмар накомпилирует таск-раннер - тебе не нужно его читать, а браузер справится - и между двумя твоими вариантами - со вторым вариантом он справится лучше.

[Serj-One]

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

>> "А в понимании движка браузера - минификация и оптимизация - главное и основное."
Браузеру плевать на минификацию, она может повлиять только на скорость загрузки, и то не критично (но речь сейчас не об этом, против минификациии я, конечно, ничего не имею, это безвредная оптимизация).
extend работу браузера тоже никак не ускорит, разве что, скорость загрузки файла стилей, но смысла в экономии пары килобайт, жертвуя поддерживаемостью и структурой, нет априори (про исходники см. выше).

>> "и между двумя твоими вариантами - со вторым вариантом он справится лучше."
Сильное заявление. Откуда данные?

[Никита Кит]

Serj-One: "Сильное заявление. Откуда данные?"
ООП учил в отличие от некоторых. И знаю что легче придать свойство массиву, а не писать это свойство дважды. Прочитать 2 класса и отрендерить одно свойство легче, чем прочитать класс, отрендерить ему свойство и повторить это заново. Если ты этого не понимаешь (а ты этого не понимаешь) - ты плохой разработчик.

[Serj-One]

Никита Кит: Поскольку ты сразу переходишь к оскорблениям, аргументов, я так понимаю, не будет? Хотя, это было очевидно изначально, твоё эго куда объёмней знаний). Ты даже не понимаешь, какой абсурд несёшь в попытках отстоять свою правоту