Здравствуйте, товарищи! Меня зовут Валик и сегодня мы поговорим про подход Atomic CSS в верстке, разработку инструментов и смежные темы.
Кратко вспомним базу - почему Atomic CSS. Рассмотрим популярные решения для работы в этом подходе и сравним их с моим изобретением - mlut. Разберем проблемы известных инструментов и посмотрим, как я решил их в своем. Будут интересные архитектурные решения, технические детали и немного хардкора.
Те, кто занимается версткой, смогут по-другому взглянуть на Atomic CSS и, возможно, взять в работу новый инструмент. А те, кто пишет системный код и тулинг - получить вдохновение и перенять нестандартный опыт.
Это расшифровка моего доклада с HolyJS Spring 2024. Можете глянуть запись, а можете почитать эту статью с некоторыми дополнениями и более выверенными формулировками.
Пару слов о себе
Я разработчик, в IT больше 8 лет. Последние 2, в основном занимаюсь бэкендом на Node.js и тулингом, а до этого, больше работал с фронтом. Делаю свой open source проект. Выступаю на IT-мероприятиях и веду местное IT-сообщество в Питере на 500+ человек.
Почему именно я буду рассказывать про Atomic CSS?
В теме с 2018, когда Tailwind еще был noname библиотекой
Смотрел все релевантные инструменты, у которых больше 20 звезд на гитхабе
3 года карьеры много верстал
В разработку своего инструмента вложил уже сильно больше 1000 часов
База про Atomic CSS
Напомню, что Atomic CSS - это методология верстки, в которой мы используем маленькие атомарные CSS-правила, каждое из которых делает одно действие. Эти классы еще называют утилитами. Часто они применяет одно CSS-свойство (например, меняет цвет текста), но не обязательно одно. В коде выглядит это примерно так:
![Верстка в Atomic CSS](https://habrastorage.org/getpro/habr/post_images/696/841/e9b/696841e9b5f3d771b4b0a9a2cbfda29b.jpg)
Основные преимущества подхода
В сравнении с рукописным CSS:
Тратим меньше мыслетоплива. Не нужно думать про уникальные названия сущностей, БЭМ-блок это или БЭМ-элемент, какую делать структуру каталогов и etc
Меньше CSS на клиенте. С определенного момента разработки, стили перестают добавляться. Мы постоянно реиспользуем одни и те же утилиты
Быстрее пишем стили. Особенно, если используем короткие названия утилит. Плюс, нам сильно меньше нужно переключаться между файлами
Кто-то наверняка сейчас вспомнил типичные мифы об Atomic CSS, часть из которых есть на иллюстрации ниже. Разбирать в этой статье я их конечно же не буду, поскольку здесь у нас больше про системный код и тулинг. Но к ним мы обязательно вернемся в моем следующем докладе на эту тему.
![Мифы об Atomic CSS](https://habrastorage.org/getpro/habr/post_images/e7c/f98/474/e7cf9847454b934ae72a0037a11cca66.jpg)
State of Atomic CSS
Разберем текущую ситуацию на рынке. Возьмем 3 актуальных и достаточно популярных инструмента для работы в Atomic CSS:
Tailwindcss - многим известный и самый популярный
UnoCSS - не просто фреймворк, а движок для создания своего фреймворка
Atomizer - старый добрый инструмент от Yahoo, которому есть чем похвастаться
Несмотря на то, что у нас есть, как минимум 3 инструмента, актуальными остаются следующие проблемы:
Неконсистентный нейминг
Неудобно писать сложные утилиты
Связь с рукописным CSS
Неудобно расширять
Далее мы рассмотрим эти проблемы подробнее
Неконсистентный нейминг
Несколько примеров утилит из популярных библиотек
flex
=>display: flex
, ноflex-auto
=>flex: 1 1 auto
tracking-wide
=>letter-spacing: 0.025em
normal
: line-height, font-weight или letter-spacing?
Сложные утилиты
Примерно так нам предлагают писать нестандартные media-выражения:
[@media(any-hover:hover){&:hover}]:opacity-100
Превращается это в следующий CSS:
@media(any-hover:hover) {
.\[\@media\(any-hover\:hover\)\{\&\:hover\}\]\:opacity-100:hover {
opacity: 1;
}
}
Со сложными селекторами тоже не все гладко:
[&:not(:first-child)]:rounded-full
.\[\&\:not\(\:first-child\)\]\:rounded-full:not(:first-child) {
border-radius: 9999px;
}
Различные at-rules также оставляют желать лучшего:
supports-[margin:1svw]:ml-[1svw]
@supports (margin:1svw) {
.supports-\[margin\:1svw\]\:ml-\[1svw\] {
margin-left: 1svw;
}
}
Связь с рукописным CSS
Тут стоит раскрыть страшную тайну Atomic CSS:
В большинстве проектов, какую-то часть CSS вам придется написать руками!
И это нормально, поскольку такого кода будет в предела 10%, как показывает практика.
Теперь о самой проблеме. Посмотрим на следующий пример кода на Tailwind:
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer components { /* #5 */
.card {
background-color: theme(colors.white); /* #7 */
border-radius: 5px / theme(borderRadius.lg);
padding: 1rem theme(spacing[2.5]); /* #9 */
}
}
Что мы здесь видим:
Конфликты с CSS. Не так давно в CSS появились каскадные слои, которые объявляются через at-rule
@layer
. А в Tailwind есть свой@layer
(строка #5), который работает как-то по своемуСтруктура файлов. По умолчанию в Tailwind можно работать только в одном CSS-файле. Чтобы работать с несколькими, потребуется подключить PostCSS плагин
Использование значений утилит. Если вы хотите получить значения утилит для использования в каком-нибудь свойстве, вам понадобится специальная функция
theme
(строка #7). При этом, вам надо будет знать, как в словаре темы до нужного значения добраться, и это не всегда очевидно (строка #9)Нет фич препроцессоров. Это скорее минус со звездочкой, поскольку фичи эти не всем нужны, да и часть из них можно получить с помощью PostCSS
Еще один интересный момент в эту тему. Одно время был такой клон Tailwind - Windi CSS. Там ребята для решения вопроса с рукописным CSS начали делать свой, то ли язык, то ли препроцессор. Вот тут можно ознакомиться, выглядит оно забавно
![Windi Lang Draft](https://habrastorage.org/getpro/habr/post_images/c09/2c5/0aa/c092c50aaefdef88e7c6bd5ca0d281ce.jpg)
Неудобно расширять
Добавить относительно простую утилиту нам предлагают следующим образом:
module.exports = {
theme: {
tabSize: {
// map with values
}
},
plugins: [
plugin(function({ matchUtilities, theme }) {
matchUtilities(
{
tab: (value) => ({
tabSize: value
}),
},
{ values: theme('tabSize') }
)
})
]
}
А для добавления своего variant (модификатора, чтобы утилита работала по hover, например), надо написать что-то такое:
variants: [
// hover:
(matcher) => {
if (!matcher.startsWith('hover:'))
return matcher
return {
matcher: matcher.slice(6),
selector: s => `${s}:hover`,
}
},
],
Актуальное решение
В качестве решения вышеперечисленных проблем я предлагаю вашему вниманию свой инструмент: mlut
![mlut - аббревиатура от My Little UI Toolkit](https://habrastorage.org/getpro/habr/post_images/85c/34c/f74/85c34cf74d133ff02cb570a1d68efaa4.jpg)
Atomic CSS toolkit with Sass and ergonomics for creating styles of any complexity
В этом посыле каждое слово имеет значение, но сейчас объясню, почему выделен именно Sass
![Нет, это не Tailwind на Sass](https://habrastorage.org/getpro/habr/post_images/a33/787/013/a3378701323b8de97dd76bbdcd6334c3.jpg)
Кто-то может подумать: "Sass - это уже легаси технология, ванильный CSS уже ого-го: кастомные свойства, каскадные слои etc". Но я бы не торопился его хоронить.
Да, с развитием CSS, некоторые его фичи стали менее актуальны, но несмотря на это он стабильно развивается, а загрузок в неделю на npm у него больше, чем у того же Tailwind. И Sass не просто мейнтейнится, а в него прямо фичи добавляются: за последние полгода было, как миниму 4 минорных релиза!
![Статистика релизов Sass](https://habrastorage.org/getpro/habr/post_images/6b0/e11/6ae/6b0e116ae1625bbffa50d08e1de3a024.jpg)
Далее перейдем к технической части, приготовьтесь)
![](https://habrastorage.org/getpro/habr/post_images/3bf/561/a17/3bf561a17bb923a9868a65f32a1562d3.jpg)
Как устроены утилиты
Мы достаточно много будем говорить про устройство утилит, поэтому начну с общей схемы их устройства
Сейчас она вам мало понятна, но далее мы разберем ее подробнее. А пока она будет сопровождать нас как эдакая мини-карта, которая поможет сориентироваться: на какой стадии разбора утилит мы находимся. И первым делом мы поговорим про нейминг
Нейминг
Рассмотрим, как обстоят дела у популярных инструментов
Tailwind
Какого-то согласованного нейминга здесь нет. Утилиты имеют opinionated названия, созвучные с CSS-свойствами или значениями. Рассмотрим пару примеров:
justify-*
: content, items, self?bg-none
- убрать весь background? Нет, толькоbackground-image
flex
=>display: flex
, ноflex-auto
=>flex: 1 1 auto
UnoCSS
Напомню, что UnoCSS - это движок, а не просто фреймворк. Он позволяет собрать свой фреймворк из так называемых пресетов. Есть уже много готовых пресетов, либо можно написать свой. В частности, подключив один из таких пресетов можно использовать синтаксис некоторых популярных библиотек. Чаще всего используется Tailwind
![](https://habrastorage.org/getpro/habr/post_images/939/bc2/329/939bc23290378fc92a121470463b3015.jpg)
Но в этом примере мы возьмем пресет с Tachyons - некогда популярной библиотекой. Правда здесь с неймингом все еще более плачевно:
br-0
=> border-right-width: 0
, но br1
=> border-radius:.125rem
b
: bottom, border, display: block
? Нет, это font-weight:bold
!
normal
: line-height, font-weight, letter-spacing?
Atomizer
Тут ситуация с неймингом получше. В основе используются сокращения Emmet и добавляются новые, по их подобию. Выглядит вполне консистентно:
Js(c)
=> justify-self: center
Bg(n)
=> background: none
Bgbm(c)
=> background-blend-mode: color
mlut
В mlut используется единый алгоритм для всех сокращений. Несколько примеров:
Js-c
=> justify-self: center
Bdr
=> border-right: 1px solid
Bdrd1
=> border-radius: 1px
Я прекрасно понимаю, что сокращения - это спорная тема. У них есть свои плюсы и минусы
Плюсы |
Минусы |
---|---|
Лаконичный код |
Есть порог входа |
Удобнее писать |
Подойдут не всем |
Чуть меньше вес кода |
![Лаконичный код, удобнее писать...](https://habrastorage.org/getpro/habr/post_images/52b/403/97b/52b40397be084ce940551348e9cd1ab0.jpg)
Кому-то они вообще не зайдут чисто эстетически, и это тоже норм. В их защиту добавлю, что сокращения окружают нас везде:
В языках:
const
,int
,char
В утилитах:
cd
,pwd
,ls
Low-level:
Ldar
,Star
,SubSmi
Вопрос со *
Напишите в комментах, кто узнал последние сокращения
Зачем алгоритм сокращений?
Избежать коллизий с новыми свойствами и значениями в CSS, поскольку он бурно развивается последние годы
Возможность выводить свойства "в голове", а не зазубривать их. Прокрутив так и использовав утилиту пару раз, вы быстро доведете ее до автоматизма, и больше не потребуется тратить мыслетопливо на ее вспоминание
Читатель может сказать, что есть уже готовые сокращения Emmet, которые кто-то даже успели выучить) Да, они неплохие, но их проблема в том, что там нет четкого алгоритма. Это подтвердил Сергей Чикуенок - создатель Emmet (спрашивал его об этом). Так что первую проблему они не решают.
Как это было
Мало кто знает, но есть такой npm-пакет: mdn-data. В нем лежат несколько больших JSON'ин, которые содержат в себе данные почти обо всем CSS. О свойствах, их синтаксисах, медиа-фичах и многом другом. К нему я постоянно обращался во время ресерча.
![JSON со всеми CSS-свойствами](https://habrastorage.org/getpro/habr/post_images/13a/ce9/235/13ace923516125651d5c22281c7993ec.jpg)
Конечно же, я изучал спеки CSS. Много спек: как стабильных, так и черновиков.
![Часть спек, которые я смотрел](https://habrastorage.org/getpro/habr/post_images/a93/cac/ee5/a93cacee5ff15b302fb4dd6d45c9ca1e.jpg)
Еще мне очень помогли данные из Chrome platform status. Это статистика частоты использования CSS-свойств в интернете. Да, такое тоже есть.
![Chrome platform status](https://habrastorage.org/getpro/habr/post_images/e13/d80/8ab/e13d808ab66b2bc5d27ba7a4db89ee5f.jpg)
В результате ресерча, у меня появилась вот такая табличка на все свойства, где они разбиты на группы и большинству присвоен рейтинг по популярности (это уже готовая таблица с сокращениями):
![Таблица CSS-свойств и их сокращений](https://habrastorage.org/getpro/habr/post_images/cf4/9d6/4b5/cf49d64b5e3a2444eda2a8070dd37c77.jpg)
Ну и конечно, это были недели размышлений, проб, ошибок и вот этого всего...
Так родился алгоритм сокращений, который мы сейчас разберем
Общий алгоритм сокращений
Целиком он расписан в документации, а здесь мы рассмотрим его по верхам:
Находим свойства, которые начинаются с одинаковой буквы
Составляем их рейтинг по популярности (в основном, но не только)
Выделяем группы с одинаковым первым словом
Составляем сокращения внутри групп
На последнем скрине с таблицей как раз результат работы по этому алгоритму. Стоит уточнить, что общий алгоритм используется, в первую очередь, для составления новых сокращений. То есть, те сокращения, которые уже есть, больше не поменяются. Это значит, что на практике вы будете использовать алгоритм для сокращения одной сущности, которые мы рассмотрим далее. А общий нужен больше для общего понимания, так сказать.
Алгоритм сокращения одной сущности
I. Название сокращаем до первой буквы свойства/значения: color
=> C
II. Если название из нескольких слов, то берется первая буква из каждого слова: color-adjust
=> Ca
III. Если два названия имеют одну и ту же начальную букву, то в следующем названии, при сортировке их по рейтингу, добавляется буква
color
=>C
cursor
=>Cs
IV. Если название из N слов, то буква добавляется в соответствующем по порядку слове
color
=>C
cursor
=>Cs
color-scheme
=>Csc
Порядок добавления буквы
В предыдущем алгоритме был пункт про добавление буквы в том случае, если получившееся сокращение уже есть. Сейчас мы конкретизируем его порядок, потому что он важен
I. Согласная следующего слога: cursor
=> Cs
Если следующий слог начинается на гласную, то берется ближайшая предыдущая согласная от нее
II. Следующая согласная
content
=>Сt
contain
=>Cn
III. Следующая гласная (без перескока через согласную)
content
=>Сt
counter-increment
=>Coi
А теперь давай поупражняемся! Мы же не зря столько разбирали алгоритм сокращений. Ниже будет несколько спойлеров: в title - сокращение, а внутри - свойство, которое ему соответствует. Попробуйте прокрутить их по алгоритму сокращения сущности, учитывая порядок добавления букв
Ps
position
Fnw
font-weight
Tf
transform
Flg
flex-grow
Слабые места
Популярность свойств меняется. Вполне возможен случай, что появится какое-то новое CSS-свойство и резко станет популярным. Тогда при составлении его сокращения в голове могут возникать ошибки, поскольку выведенное сокращение уже будет занято каким-то старым свойством. Хотя этот минус будет больше актуален для новых пользователей mlut
Редкие длинные свойства может быть сложно вспомнить
Возможны спорные ситуации, по мере развития CSS. Алгоритм достаточно формален, чтобы написать программу, которая могла бы из JSON превращать свойства в сокращения. Но проблема в том, что первоисточник здесь не JSON, а спеки, и там все не так однозначно. Надо следить за их развитием, смотреть, куда движутся те или иные свойства/фичи. И уже на основе этих вводных использовать алгоритм. Но пока спорных ситуаций почти не было
Синтаксис
Посмотрим, что нам предлагают популярные инструменты
Tailwind
Здесь нет даже какого-то подобия спецификации. По большей части, синтаксис является набором ad-hoc решений с костылями в виде arbitrary частей. Кратко пройдемся по нему.
Утилита и значение:
util-value
- просто значение-util-2
- отрицательные значенияutil-[42px]
- произвольные значения[css-prop:value]
- произвольное CSS свойство и значение
Variants:
variant:util-value
- селекторы и некоторые at-rulesgroup/name:util-value
- группы с именами@md:util-value
- container queries
Arbitrary variants
variant-[.class]:util
- произвольные значения variant[&:nth-child(3)]:util
- произвольный variant@[17.5rem]:util
- container queries
UnoCSS
Эту часть мы пропускаем, поскольку в Uno чаще всего используется синтаксис Tailwind. По крайне мере, он самый продвинутый из имеющихся там вариантов.
Atomizer
Внезапно, но тут есть спецификация! Правда судя по ней, синтаксис покрывает достаточно мало возможностей CSS.
[<context>[:<pseudo-class>]<combinator>]<Style>[(<value>,<value>?,...)][<!>][:<pseudo-class>][::<pseudo-element>][--<breakpoint_identifier>]
Разбирать ее сейчас мы конечно же не будем. Я просто вставил ее, дабы показать, что она в принципе есть. Для сравнения: в Tailwind мне пришлось пробежать по всей доки в поисках вариантов синтаксиса. Здесь же я зашел на одну страницу, разобрал эту спеку и уже имею представление, какие могут быть утилиты и на что они в принципе способны.
mlut
В mlut реализован, так называемый Components Syntax, благодаря которому, компактные утилиты мы можем разворачивать в сложные CSS-правила
@:ah_O1_h
=>
@media (any-hover) {
.\@\:ah_O1_h:hover {
opacity: 1
}
}
Понимаю, что сейчас это было больше похоже на мем "Как нарисовать сову", но не беспокойтесь: далее мы разберем этот же самый пример
![Как нарисовать сову](https://habrastorage.org/getpro/habr/post_images/086/de8/e8a/086de8e8a490bfa8b1377554c7709623.jpg)
Зачем проектировать синтаксис?
Основная цель - концептуальная близость с CSS для органичного развития вместе с ним
Less opinions, more standards! (c) Я
Хорошо спроектированный синтаксис позволяет нам:
Меньше учить "фантазийных" сущностей
Избежать (минимизировать) конфликты с CSS
Сохранить удобство написания
Получить высокую выразительность для реализации наибольшего количества фич CSS
Ну мы с вами уже смешарики и знаем, как ресерчить CSS. Поэтому достаем ранее упомянутые инструменты, обмазываемся спеками и вот это вот все
![Процесс исследования CSS](https://habrastorage.org/getpro/habr/post_images/e10/07d/04f/e1007d04fe8a55e17dd9068a1e49c702.jpg)
Правда в этот раз, я изучал не просто черновики спек, а "черновики черновиков". Так можно назвать тематические issues в том самом репозитории csswg, где идет обсуждение спек. Он также есть на скрине выше
Интересный факт
Вы знали, что большую часть спек CSS написали 2 человека? Tab Atkins и Elika Etemad
Первую версию синтаксиса я проектировал около 2 недель и часто был примерно в такой ситуации:
![Процесс проектирования синтаксиса mlut](https://habrastorage.org/getpro/habr/post_images/80a/e16/393/80ae163937d2b3afe3b499eb7868fd50.jpg)
И вот что у меня получилось...
Utility components syntax
Синтаксис, в котором утилита разделяется на компоненты, каждый из которых, соответствует части CSS-правила. Под частями здесь подразумеваются at-rules, селектор, свойства и их значения. А теперь, вернемся к одному из предыдущих примеров и взглянем на него по-другому:
![](https://habrastorage.org/getpro/habr/post_images/5b1/d1f/3b0/5b1d1f3b005a751458ae0a20756d52c1.jpg)
Настало время разобраться со схемой устройства утилит, которая сопровождала нас на протяжении статьи:
CSS at-rule: брейкпоинты,
@supports
, etcpre-states - часть селектора перед классом утилиты
Имя
Значение
post-states - часть селектора после класса утилиты
Здесь стоит немного отойти в сторону и ввести такое понятие как конвертация, поскольку дальше оно будет много где упоминаться.
Конвертация - превращение сокращения из названия класса в реальную CSS-сущность. Она встречается почти во все частях утилит: значениях, states, at-rules и т.д.
States
Перед тем, как вернуться к синтаксису утилит, нам надо вспомнить, какие по сложности бывают селекторы в CSS:
Simple selector - с одним условием:
.class
,#id
,element
(Pseudo-)Compound selector - несколько простых селекторов без комбинаторов:
.class[attr]
,element.class
Complex selector - несколько simple/compound c комбинаторами:
.class:hover + .item
Selector list - comma-separated список из simple, compound или complex:
.class, .item + .item, a.active
Так вот, states в mlut - это упрощенный selector list. Это значит, что в них мы можем использовать почти все возможности селекторов CSS с похожим DX. Даже множественный селектор (через ,). Основные отличия синтаксиса в следующем:
:
- объединение стейтов,
- разделение на список<empty>:
- пробел в селекторе
Рассмотрим пару примеров
![Утилита с post states](https://habrastorage.org/getpro/habr/post_images/a8e/675/272/a8e6752728859d9336f6d8603ef9d702.png)
![Утилита с pre states](https://habrastorage.org/getpro/habr/post_images/408/73d/4a7/40873d4a708b6db4a3e3c37b091e4d20.png)
At-rules
Перед разбором устройства at-rules в нашем синтаксисе, вспомнил их некоторые особенности в CSS. At-rules в CSS также бывают разные по сложности. Есть совсем простые, типа @import
и @charset
. Есть вложенные, типа @layer
. А самые сложные называются conditional at-rules - о них и поговорим далее.
Как устроены conditional at-rules:
Conditions - сами условия. Они могут состоять из операторов, скобок и features / queries, в зависимости от спеки:
(hover) and (min-width: 20rem)
Операторы - логические:
and
,or
,not
Features - выражения, функции, etc:
(pointer: fine), style(color: green)
В примере ниже мы можем заменить, что у нас есть <supports-condition>
, который содержит в себе все остальное:
![Синтаксис @supports из спеки](https://habrastorage.org/getpro/habr/post_images/1b7/66f/2bd/1b766f2bd7cc1176aedf8453d32b4444.jpg)
Что еще стоит понимать о conditional at-rules:
Состав очень разный
Можно строить сложные выражения, используя операторы
Можно вкладывать друг в друга
![Синтаксис @media из спеки](https://habrastorage.org/getpro/habr/post_images/5ad/74d/de6/5ad74dde64f82e13cd1a371a1cbb4dc9.jpg)
А теперь об at-rules в mlut. Сюда входят breakpoints и сами at-rules.
Breakpoints имеют отдельный подсинтаксис, поскольку используются намного чаще, чем другие варианты at-rules. При этом, кроме стандартного поведения, когда утилита включается только с определенного размера экрана, нам может понадобиться и такое, чтобы утилита работала только в диапазоне ширин или до какого-то размера. Поэтому здесь и нужен подсинтаксис.
/* sm:md,xl_P2r */
@media (min-width: 520px) and (max-width: 767px), (min-width: 1200px) {
.sm\:md\,xl_P2r {
padding: 2rem;
}
}
Ну и сами rules: @media
, @supports
и прочие.
Для составления сложных выражений в обоих синтаксисах, используются следующие операторы:
:
=>and
,
=>,
(or)
Далее рассмотрим, как работают rules в at-rules) У каждого правила есть:
Сокращение:
m
,s
,c
- составляется по известному нам алгоритмуКонвертер - превращает сокращения в цепочку CSS-выражений
Кастомные значения - алиасы для часто используемых цепочек. Их может добавить пользователь через конфиг
Таким образом, синтаксис at-rules в mlut позволяет закрыть весь класс этих фич в CSS. Это означает, что если в CSS добавится новое at-rule, то с большой вероятностью, его можно будет реализовать в mlut, без изменения синтаксиса и доработок в ядре. Далее рассмотрим несколько примеров.
![Утилита со сложным @media](https://habrastorage.org/getpro/habr/post_images/c57/97d/f13/c5797df130e6736b013eadbddb6897fa.png)
И да, at-rules в mlut можно комбинировать!
![Утилита с несколькими at-rules](https://habrastorage.org/getpro/habr/post_images/188/5e3/136/1885e3136185ab42f18302736018ceba.png)
Да, первая реакция может быть примерно следующая:
![Ну нафиг!](https://habrastorage.org/getpro/habr/post_images/d2e/dd2/887/d2edd2887d067e40ff5ceb45d71b5bae.jpg)
Но как по мне, синтаксис получился мощный) И несмотря на это, слабые стороны у него все же имеются:
Нельзя (пока) написать произвольный псевдоселектор. Сейчас это сконвертируется вот так:
D-f_:pseudo
=>.D-f pseudo {...}
Возможны конфликты пользовательских алиасов в at-rules (
-myQuery
) с CSS custom media или cutsom selector. Но это не точно, поскольку там еще совсем черновики
Конвертация значений
Мы ранее уже немного касались понятия конвертации. Напомню, что так называется превращение сокращения из названия класса в реальное CSS-значение.
ml-1
=> margin-left: 0.5rem
D-f
=> display: flex
Как обстоят дела у конкурентов других инструментов
Tailwind
Здесь конвертация достаточно скромная. Вот что он умеет:
Подстановка значения из словаря в конфиге (theme)
Прозрачность цветов:
bg-sky-500/75
Императивная конвертация, которую мы пишем руками, при добавлении утилиты через плагин
Части arbitrary значений, как например: более удобная запись custom properties
UnoCSS
Тут все примерно так же, как в Tailwind
![](https://habrastorage.org/getpro/habr/post_images/939/bc2/329/939bc23290378fc92a121470463b3015.jpg)
Atomizer
Тут есть пара интересных мест, но тоже ничего особенного:
Подстановка значения из словаря + RTL by design
Прозрачность цветов:
C(#fff.5)
Удобный синтаксис для custom properties
Множественные значения(!):
Bgp(20px,50px)
Подстановка пользовательских значения из конфига
mlut
В mlut разработана система конвертации для почти произвольных значений. Пара примеров для затравки:
Ml-1/7
=>margin-left: -14.3%
Bdrd1r;2/5p
=>border-radius: 1rem 2px / 5%
Зачем система конвертации?
Значения свойств CSS - это сложно. Чуть дальше вы в этом убедимся
Хотим оставаться ближе к платформе - вспоминаем предыдущие принципы проектирования инструмента
Хотим чтобы все это было удобно писать
В чем трудности работы со значениями CSS? Стоит начать с того, что для их описания (и не только для этого) есть специальный Value Definition Syntax! А в самих значениях у нас могут быть: разные типы данных, единицы измерения, функции и еще много чего...
Но мы с вами сложностей не боимся, поэтому идем в спеку - изучаем Value Definition Syntax
![Value Definition Syntax в спеке](https://habrastorage.org/getpro/habr/post_images/a6f/563/7d1/a6f5637d128b57330bbbf7e8e82634de.jpg)
Смотрим доклад Ромы Дворнова с HolyJS Moscow 2019 - закрепляем материал... И теперь, когда мы будем смотреть на описание CSS-свойств в mdn-data, мы поймем, какие значения оно может принимать. А посмотрев на несколько таких свойств, мы начнем видеть закономерности и общие моменты, что поможет спроектировать нашу систему конвертации ближе к реальности.
![](https://habrastorage.org/getpro/habr/post_images/1a7/a9a/52b/1a7a9a52bb777e7d82c38ea7e6a636d9.jpg)
![](https://habrastorage.org/getpro/habr/post_images/e7a/d41/b6a/e7ad41b6a9a38edbd0554ce1013570a6.jpg)
![](https://habrastorage.org/getpro/habr/post_images/51e/0af/8bb/51e0af8bbe52466bf06916ca5c69364a.jpg)
Интересный момент, что в mdn-data есть еще JSON, куда вынесены синтаксисы, которые реиспользуются в разных свойствах (и не только свойствах). Это хорошо помогло при выявлении каких-то паттернов в значениях.
![JSON с синтаксисами CSS](https://habrastorage.org/getpro/habr/post_images/b07/8b3/d0e/b078b3d0ec69aa2c8d9007672e1fe8c2.jpg)
Основные понятия конвертации
Конвертер - функция, которая преобразует значение из сокращенного класса в реальное CSS значение.
Трансформер - функция, которая может еще как-то изменить готовое CSS-значение. Указывается в опциях утилиты.
Тип конвертации - список конвертеров, которые применяются к значению утилиты. Есть у каждой утилиты и если не указан явно в опциях утилиты, то применяется дефолтный.
Для дальнейшего понимания, стоит немного разобраться, как представлены утилиты mlut в коде. Все утилиты хранятся в едином реестре. Сейчас немного упростим, но по сути, это большой словарь, где ключи - названия утилит, а значения - опции. В опциях может быть название свойства, тип конвертации и еще много чего.
'Apcr': (
'properties': aspect-ratio,
'conversion': 'num-length', /* тип конвертации */
),
Помимо реестра, есть общий конфиг для утилит. В нем хранятся какие-то настройки, связанные со всеми или с большим группами утилит. В частности, тут лежат типы конвертации. Это словарь, ключи в котором - название типа, а значения - цепочка конвертеров.
'conversion-types': (
/* ... */
'num-length': ('num-length', 'global-kw', 'cust-prop')
/* ^цепочка конвертеров */
),
Общая схема работы конвертации
Полное значение утилиты разбивается (по пробелам или разделителю) на простые значения
Каждое простое значение проходит по цепочки конвертеров до тех пор, пока 1 из них не сработает
К CSS значению применяется трансформер
Итоговое значение подставляется в CSS правило
Теперь немного подробнее рассмотрим конвертеры. Это обычные функции со следующей сигнатурой:
@function convert-uv-number($value, $data: ()) {
/* ... */
@return $new-value;
}
$value
- исходное значение$data
- словарь с дополнительными данными
Основные особенности конвертеров:
Часть имени после
convert-uv-
используется в типах конвертацииПрименяются друг за другом
Внутри может использовать другие конвертеры
Можно написать свои
И еще пару слов стоит сказать про особенности трансформеров. По сигнатуре они такие же как и конвертеры. Основное отличие: они применяются единожды ко всему итоговому CSS значению и возвращают новое итоговое значение целиком. Типичный кейс: оборот значения в CSS-функцию, например в фильтр.
Кейс: утилита для градиентов
Мы разобрали много отдельных концептов, и теперь стоит посмотреть, как это работает все вместе. Возьмем конкретный кейс: утилиту для CSS-градиентов, возможно самую сложную в mlut. Она имеет следующие опции:
'-Gdl': (
'properties': background-image,
'transformer': 'gradient',
'css-function': 'linear-gradient',
'conversion': 'gradient',
'multi-list-separator': ',',
'keywords': ('position', 'gradient'),
),
Как мы видим, тут есть, и специальный тип конвертации, и трансформер. А вот как описан этот тип конвертации в общем конфиге:
'conversion-types': (
/* ... */
'gradient': (
'keyword', 'color', 'cust-prop', 'Pl',
'number', 'angle', 'global-kw'
),
),
Здесь достаточно длинная цепочка конвертеров (плюс пайплайн - продвинутая фича), но примечательно следующее. Чтобы получить достаточно сложную логику конвертации, мне не пришлось писать кучу какого-то императивного кода. Я просто составил из имеющихся конвертеров такую цепочку и получил желаемое поведение. Вот как работает эта утилита:
![Утилита для CSS-градиентов](https://habrastorage.org/getpro/habr/post_images/989/be9/347/989be9347c9e4bda23af75c717069f1e.png)
Первая реакция может быть примерно такая:
![Что ты такое?](https://habrastorage.org/getpro/habr/post_images/da7/0b7/38e/da70b738e3e065c050840ad69b6a9747.jpg)
Но как по мне, утилита получилась шедевральная)
Слабые места
(пока) Нет first-class поддержки CSS-функций:
calc()
,clamp()
В будущем, CSS значения могут занять используемые спецсимволы:
;
,$
,?
Конфигурация
Под конфигурацией подразумевается настройка инструмента. В частности:
Добавление значений: цвета, шрифты, ключевые слова
Создание утилит
Изменение настроек: брейкпоинты, новые states
Что нам могут предложить известные инструменты?
Tailwind
Добавить значение для утилиты - вроде просто.
module.exports = {
theme: {
extend: {
fontFamily: {
display: 'Oswald, ui-serif',
}
}
}
}
Но вот чтобы добавить утилиту, надо написать плагин! При этом, утилиты бывают статические и динамические.
Статические утилиты
Вручную пишите CSS(-in-JS)-правило
Будут доступны variants
module.exports = {
plugins: [
plugin(function({ addUtilities }) {
addUtilities({
'.content-auto': {
'content-visibility': 'auto',
},
'.content-hidden': {
'content-visibility': 'hidden',
},
})
})
]
}
Динамические утилиты
Можно добавить словарь со значениями
Будет доступен arbitrary синтаксис
Будут доступны variants
module.exports = {
theme: {
tabSize: {
// map with values
}
},
plugins: [
plugin(function({ matchUtilities, theme }) {
matchUtilities(
{
tab: (value) => ({
tabSize: value
}),
},
{ values: theme('tabSize') }
)
})
]
}
UnoCSS
Добавлять значения здесь тоже достаточно просто:
theme: {
// ...
colors: {
'veryCool': '#0000ff', // class="text-very-cool"
},
}
Но с утилитами ситуация похуже. Здесь для этого есть неплохой и лаконичный api. Самые простые утилиты можно добавить в одну строку! Но для чего-то более сложного придется писать регулярки и императивную конвертацию:
rules: [
['m-1', { margin: '0.25rem' }],
[/^p-(\d+)$/, ([, d]) => ({ padding: `${d / 4}rem` })],
]
mlut
В mlut все расширения делаются в одном конфиге и как правило: парой строк кода.
Как добавить новую утилиту?
@use 'mlut' with (
$utils-data: (
'utils': (
'registry': (
'Mm': margin-magick,
),
),
),
);
Бойлерплейта чуть больше, но простая утилита так же добавляется в одну строку. При этом, вот что она умеет из коробки, в плане конвертации:
Числовые значения:
Mm1r
=>margin-magick: 1rem
Глобальные ключевые слова:
Mm-ih
=>inherit
Custom properties:
Mm-$myCard?200
=>var(--ml-myCard, 200px)
Несколько значений:
Mm10p;1/3
=>10% 33.3333%
Диспетчеризация
Сейчас мы немного отвлечемся и вспомним понятие "диспетчеризация" из программирования. Диспетчеризацией - это поиск и выбор, какая функция будет вызываться для определенного типа данных. Она бывает:
Статическая - на этапе компиляции
Динамическая - в рантайме
В качестве примера статической диспетчеризации приведу вот такой пример на C++. Да, вот так вот внезапно мы перешли от CSS к плюсам)
struct Calculator {
int (*operation)(int, int);
}
int add(int a, int b) {
return a + b;
}
int subtract(int a, int b) {
return a - b;
}
int main() {
Calculator calc;
calc.operation = add;
printf("5 + 3 = %d\n", calc.operation(5, 3)); // #17
calc.operation = subtract;
printf("5 - 3 = %d\n", calc.operation(5, 3));
return 0;
}
Здесь у нас структура с указателем на функцию. Уже на этапе компиляции будет понятно, какую реализацию функции вызывать на строке #17.
Если вы пишите на динамических языках, то с динамической диспетчеризацией (далее ДД) сталкиваетесь почти каждый день. Здесь можно вспомнить обычный поиск метода по цепочке прототипов в JavaScript. Но бывают разные варианты ДД и еще один из часто встречающихся: ДД на основе виртуальной таблицы. Смысл в том, что у нас в памяти есть некая таблица, в которой прописано, что для такого-то типа данных должна вызываться вот такая-то реализация функции. В этой статье тема разобрана более подробно и есть хорошие примеры. А для общего понимания вопроса, приведу следующий код:
class Toad {
sleep() {
// ...
}
}
class Lizard {
sleep() {
// ...
}
}
function lull(animal) {
animal.sleep(); // #14
}
const toad = new Toad();
lull(toad);
Представьте, что это не JavaScript, а какой-то другой язык с классами. На строке #14, как понять: какую реализацию метода sleep вызывать?
А теперь вопрос: как мы можем использовать эти концепции при проектировании нашей программы? Рассмотрим пример из mlut, где используется подход похожий на ДД с виртуальной таблицей.
/* _at-rules.scss */
$at-rules-db: (
'media': (
'alias': 'm',
'default': true,
),
'supports': (
'alias': 's',
),
'container': (
'alias': 'c',
),
);
/* _mk-ar.scss */
@mixin -generate-ar($at-rules, $this-util, $ar-list, $cur-index, $last-index) {
/* ... */
$converter: map.get(ml.$at-rules-db, $ar-name, 'converter');
@#{$ar-name} #{meta.call($converter, $ar-str, $this-util)} {
/* ... */
}
}
Здесь у нас отрывок из кода, в котором происходит конвертация at-rules. У нас есть $at-rules-db
- конфиг с данными обо всех at-rules: их сокращениях, конвертерах etc. Этот конфиг мы можем использовать как подобие виртуальной таблицы. Далее, в миксине -generate-ar
мы смотрим, с каким at-rule мы работаем ($ar-name
), и на основе этого, достаем из конфига нужный конвертер. Далее, применяем его к цепочке сокращений $ar-str
, которая нам пришла.
Какие преимущества у такого подхода? Он дает нам хорошую расширяемость. При добавлении нового at-rule, нам не нужно идти в код ядра и что-то править. То есть, новый at-rule можно добавить просто из конфига, при подключении библиотеки. Такой пример мы дальше и рассмотрим.
Как-то мне прислали issue с вопросом про поддержку container queries. Я ответил на него сниппетом кода в ~20 строк, которым через конфиг можно было добавить базовую поддержку этой фичи!
Для сравнения: чтобы добавить container queries в Tailwind, ребятам пришлось придумать новый синтаксис и написать плагин на 70 строк.
JIT engine
Напоследок, поговорим про JIT движки в Atomic CSS инструментах. Но для сперва, немного вспомним историю.
![Древние CSS-фреймворки](https://habrastorage.org/getpro/habr/post_images/a4c/eb7/7fa/a4ceb77fad00415d8065cf1fa06ef248.jpg)
Как работали инструменты старого поколения (Tailwind v1, Tachyons, etc):
Генерируем over9000 утилит на все случаи жизни
Используем часть из них в разметке
Добавляем в сборку программу, которая смотрит нашу разметку и удаляет неиспользуемый CSS
Какие проблемы есть при таком подходе:
Муторно или невозможно использовать произвольные значения утилит
Регулярно надо редактировать конфиг для добавления новых значений утилит
Большой CSS-бандл в режиме разработки
Для решения этих проблем появился новый подход, который называется JIT мод. Здесь нет ничего общего с JIT-компиляторами, это скорее маркетинговое название. С JIT модом все становится проще:
Пишем (почти) произвольные утилиты в разметке
JIT-движок смотрит наш код и генерирует только те утилиты, которые мы использовали
Историческая справка
Некоторые считают, что JIT-движок впервые появился в Windi CSS для решения проблем Tailwind v2. Далее, команда Tailwind украла взяла это решение себе на вооружение. Вроде это они тогда и придумали термин JIT-движок
Но мало кто знает, что JIT-движок был еще в первых версиях Atomizer, году в 2015! Зная это, забавно было смотреть на пафосные заявления его вышеупомянутых "переизобретателей", и на рассуждения Anthony Fu по теме
Общая схема работы JIT-движка:
Находим файлы с контентом
Сканируем их и достаем утилиты
Генерируем CSS для найденных утилит
И уже наша постоянная рубрика: разбор актуальных решений)
Tailwind
В основе движка здесь лежит большой PostCSS плагин. Это значит, что мы получаем, как плюсы, так и минусы PostCSS. Легко делать интеграции со сборщиками и другими плагинами из экосистемы. Но нужно работать с AST PostCSS и довольствоваться средним перфомансом.
Хотя в Tailwind v4 планируется новый движок - Oxide, который решит некоторые слабые места текущего
UnoCSS
Здесь используется самописный генератор утилит. Судя по бенчмарку и заявлениям авторов: он самый быстрый и там много оптимизаций. Есть интеграция с основными популярными сборщиками. А также, есть много дополнительных фич, как например: attributify и shortcuts
Atomizer
Тут тоже все хорошо: используется самописный генератор утилит. Он относительно простой, но с legacy-зависимостями, типа lodash. Интеграции также имеются: для большинства сборщиков есть плагины через unplugin, а для некоторых и отдельными пакетами
mlut
mlut и здесь отличился, но уже не в лучшую сторону. Сейчас разберемся почему. Здесь у нас почти как в компиляторах: есть фронтенд и бэкенд
Фронт: TypeScript |
Бэк: Sass |
---|---|
CLI / плагин |
Генератор утилит и конфиги |
JIT движок |
CSS библиотека |
Компилятор Sass |
Основной вопрос здесь в следующем: как связать Sass и JS? Нам ведь как-то надо получиить данные из Sass-конфига, передавать собранные утилиты в генератор etc. Для решения этих задач мы используем подход, который я назвал: Sass in JS
![Sass in JS](https://habrastorage.org/getpro/habr/post_images/9e3/a9d/9ce/9e3a9d9ce93ffb6260411c14087d88ac.jpg)
Суть его в следующем:
Загружаем код нужного Sass-модуля
Дописываем в него код
Компилируем итоговый скрипт в CSS
(при необходимости) Достаем данные из вывода
Как это выглядит в коде
Берем содержимое input Sass-файла (Sass точки входа) пользователя, либо дефолтный конфиг из примера ниже, если input файла нет:
/* default userConfig */
@use "sass:map";
@use "../sass/tools/settings" as ml;
Далее, в конец input файла добавляем определенный Sass-код, в котором выполняем логику. Например, достаем что-то из конфига. Компилируем получившийся код:
const { css } = (await sass.compileStringAsync(
userConfig + '\n a{ all: map.keys(map.get(ml.$utils-db, "utils", "registry")); }',
{
style: 'compressed',
loadPaths: [ __dirname, 'node_modules' ],
}
));
На выходе у нас получается вот такое забавное CSS-правило, где в свойстве all
лежит список имен всех утилит из реестра. Далее, мы просто извлекаем из него целевые данные
a {
all: "Ps", "T", "R", "B", "-X", "-Y", "-I", /* etc */
}
Стоит еще рассказать про несколько интересных особенностей Sass как языка
Нет рантайма. Код просто компилируется и выдается какой-то CSS. Поэтому тут у нас как в классическом PHP: на каждую пересборку стилей "заново создается мир" - загружаются все конфиги, в том числе, реестр утилит на 2к+ строк. Да, это не особо оптимально, но благодаря нативному Dart-компилятору Sass - работает вполне шустро. На небольшой проекте, даже быстрее Tailwind v3, особенно холодный старт. Потому что каждый старт здесь как холодный, хотя в какой-то момент, может включиться JIT в JS движке.
Мало фич в языке. Никаких классов и объектов, даже regexp нет) Но зато есть кое-что из ФП: функции высшего порядка, иммутабельные структуры данных, etc. Это покажется странным, но писать на таком языке - интересный и даже полезный опыт. Возможно, что-то подобное испытывают те, кто работает с Clojure, но это не точно, я пока не пробовал его. Идея в том, что когда в языке мало фич, это заставляет тебя комбинировать небольшое количество базовых элементов для получения сложной логики. А это один из базовых навыков хорошего инженера.
Максимальная интеграция с CSS. Одно время я думал: зачем я продолжаю писать сложную программу на Sass, вместо того, чтобы переписать все на Rust JS. Одним из ответов как раз и была "максимальная интеграция". Там, где авторов других генераторов пришлось писать логику работы с CSS-селекторами, я взял функции из стандартной библиотеки Sass. Там где в JS надо учитывать единицы измерения у чисел (1px, 1rem), в Sass такие значения - first-class citizen. Похожее можно сказать про перевод списков Sass в CSS списки и еще много что.
Заключение
Вот некоторые инсайты, которые получил за время работы над проектом
Не бойтесь безумных идей. Например таких, как: "Написать сложную программу на CSS-препроцессоре". Вполне возможно, что в процессе вы создатите, что-то инновационное и выдающееся. Либо просто получите очень полезный опыт.
Попробуйте пойти до конца, докопаться до сути проблемы. И поняв корень проблемы, придумать такое решение, которое будет устранять истинную причину так, чтобы проблема не возникала бы в принципе. Ведь часто, когда мы решаем некую задачу, мы останавливаемся на лечении какого-то следствия более фундаментальной проблемы или полу-костыльном решении. Обычно бизнес дает нам ограниченные ресурсы и такое вполне можно понять. Но как только появится возможность - попробуйте вышеописанный подход.
Неудача - тоже результат. Как говорил астрофизик Константин Батыгин:
99% процентов работы ученного - это фейлы.
Даже если вам с первой попытки не удалось сделать самый быстрый фреймворк - не стоит расстраиваться. Вы получили полезный опыт, который как-то изменил и прокачал вас. Например, из этого можно сделать хороший доклад и попасть спикером на tier 1 конференцию)
Ну и напоследок, хочу еще раз пояснить, зачем я все это делал.
Я пытался решить проблемы существующих инструментов, которые мы разбирали в начале. Мне хотелось попробовать максимально реализовать потенциал подхода Atomic CSS. Я этим загорелся, поскольку мечтал работать с таким инструментом, но в тот момент, на рынке его не было.
Я хочу показать сообществу все эти нестандартные идеи и интересные технические детали, которые есть в mlut. Я думаю, что это хотя бы немного поможет развитию индустрии. Поэтому прямо сейчас занимаюсь продвижением инструмента и в идеале хочу, чтобы он попал в опрос State of CSS. Так что буду благодарен за любой фидбек и помощь в этом.
У меня есть мечта: я хочу стать фултайм open source разработчиком. Проект я вижу как начало своей карьеры в этом деле и "разминку перед большой игрой". Добавлю, что у меня нет цели "захватить мир" с mlut или "убить" Tailwind. Я прекрасно понимаю, что инструмент скорее нишевый и не имеет такого потенциала by design. Но мне хотелось бы уверенно зайти на рынок, пободаться с топовыми аналогами, найти свою аудитории и принести этим людям пользу!
Под конец, процитирую классика:
Это родилось в борьбе за воплощение мечты
И навсегда сохранит в себе ее черты
На этом все! Подписывайтесь на мой телеграм канал, ставьте звезды на гитхабе mlut, ну и буду рад видеть ваши комменты!
Комментарии (11)
pvasili
05.08.2024 10:43+3Изобретение очередного эсперанто чисто ради самого эсперанто когда все отлично общаются на своих языках.
Для паролей - точно пойдёт :)
misterzsm Автор
05.08.2024 10:43Если бы "все отлично общались на своих языках", то не появились бы разные подходы, такие как: БЭМ, Atomic и т.д.
Denioo
05.08.2024 10:43+2Как опыт для резюме пойдет, как юзабельная вещь в текущих реалиях врятли.
Больше походит на то что сами придумали проблему, сами решили.
До сих пор не понимаю что все плачут над написанием этих стилей и пытаются максимально усложнить себе работу, прикручивают всякие tailwind/bootstrap или изобретают велосипеды, когда даже ванильный css сильно продвинулся. У вас ограничение стоит на использование букв? Или нравится так часто подглядывать в документацию - этакие вуайеристы документаций, когда вместо того чтобы потратить 1-2 минуты на написание класса со всеми свойствами, мы тратим 10 на просмотр документации как описать это свойство в classname.misterzsm Автор
05.08.2024 10:43Повторюсь, что если бы с написанием стилей все было легко, то не появились бы разные подходы и инструменты.
Ограничения на буквы нет, но так удобнее. Вряд ли кто-то будет спорить, что удобнее написать:
npm i -D mlut
, чемnpm install mlut --save-dev
И стоит понимать, что это инвестиционная история: 1 раз приложил усилия, разобрался в этих сокращениях, и потом всю оставшуюся практику наслаждаешься версткой) В этом случае, постоянно смотреть в доку не потребуется
dom1n1k
05.08.2024 10:43Очевидно, что описанная система не взлетит. Почему взлетел тайлвинд? Разумеется, там комплекс причин, но одна из главных - супер-низкий порог входа. Это как в своё время было с jQuery: cмотришь на страничке get started буквально первый же пример и понимаешь его. Дальше по ходу дела всплывёт много нюансов, но базовая идея становится ясна сразу и интуитивно.
Здесь же мысли примерно такие:
боже что это? ничего не понятно...
причем о смысле происходящего речь вообще не идёт
объясните хотя бы, как эти хэши на отдельные токены разобрать?
даже разбираться не хочу
ладно, посмотрим доку
так-так... угу-угу...
нет, точно не хочу.Со многим в статье не согласен. Особенно смешно, как автор относит плохо читаемую разметку к "мифам", и тут же усовершенствует её так, чтобы стало ещё лучше, ещё удобнее.
Тем не менее, плюсов я отсыпал. При всём моём несогласии, статьи с таким уровнем погружения нам нужны. Они помогают понимать, что происходит в головах людей с отличающимся мировоззрением.
misterzsm Автор
05.08.2024 10:43Добавлю, что у меня нет цели "захватить мир" с mlut или "убить" Tailwind. Я прекрасно понимаю, что инструмент скорее нишевый и не имеет такого потенциала by design
Хотя про взлет: в свое время, как-то нашлись N тысяч человек, которые заценили и взяли в прод Tachyons и Atomizer. Хотя там тоже используются сокращения, а mlut оба инструмента сильно превосходит. Возникает закономерный вопрос: "чем я хуже"?)
причем о смысле происходящего речь вообще не идёт
объясните хотя бы, как эти хэши на отдельные токены разобрать?Про это в статье вроде целые разделы есть. Хотя возможно, тут имеются в виду мысли того, кто смотрит инструмент
Миф в том, что разметка не читаемая только с первого взгляда. Как только разберешься - все становится норм. Вы, например, смогли отгадать свойства утилит в интерактиве? Я читал этот доклад 4 раза и почти всегда, люди угадывали их не дольше 5 секунд. Хотя в алгоритмах еще толком не успели разобраться)
P.S. за плюсы спасибо)
zoto_ff
05.08.2024 10:43Не вижу никаких преимуществ в использовании этого вашего атомик ксс. Выдумали проблемы - сделали решение
Тратим меньше мыслетоплива. Не нужно думать про уникальные названия сущностей, БЭМ-блок это или БЭМ-элемент, какую делать структуру каталогов и etc
БЭМ не нужен. Есть JSX, есть CSS Modules. Создаёшь папку для компонента, в ней рядом с index.tsx кладёшь style.module.(css|scss) – ничего не нужно придумывать.
Меньше CSS на клиенте. С определенного момента разработки, стили перестают добавляться. Мы постоянно реиспользуем одни и те же утилиты
Неправда. После сборки, минификации и сжатия обычный CSS будет весить меньше, чем ваши спагетти-классы.
Быстрее пишем стили. Особенно, если используем короткие названия утилит.
Простите, но я лучше вспомню CSS-проп, чем буду учить ваши opinionated названия классов или запоминать логику сокращений
misterzsm Автор
05.08.2024 10:43Отчасти правда, только проблема в том, что фронтенд не ограничивается SPA на JS-фреймворках)
Неправда. После сборки, минификации и сжатия обычный CSS будет весить меньше
После аглификации CSS - возможно, но опять же: ее далеко не в каждую сборку добавишь
Простите, но я лучше вспомню CSS-проп, чем буду учить ваши opinionated названия классов или запоминать логику сокращений
Ваше право. Хотя вполне логично однажды разобраться с сокращениями и дальше получать профит от них)
bromzh
05.08.2024 10:43Вот ты выучил всё это, потом приходишь на проект без mlut и за пару месяцев всё забываешь.
bromzh
Как генератор паролей пойдёт. В остальном - write-only код.
misterzsm Автор