Комментарии 23
Хватит придумать всякую ерунду. Мы хотим писать CSS.
Но сравнить можно и с SCSS:
$breakpoints: (
30em: (80%, 1rem, 1rem, block),
48em: (60%, 1.5rem, 1.125rem, flex),
62em: (40%, 2rem, 1.25rem, flex),
);
.container {
width: 100%;
padding: 0.5rem;
font-size: 0.875rem;
display: block;
@each $bp, $vals in $breakpoints {
@media (min-width: $bp) {
width: nth($vals, 1);
padding: nth($vals, 2);
font-size: nth($vals, 3);
display: nth($vals, 4);
}
}
}Или, если допускается плавное изменение, то можно вспомнить про clamp:
.container {
display: block;
width: clamp(40%, 70vw, 100%);
padding: clamp(0.5rem, 2vw, 2rem);
font-size: clamp(0.875rem, 1.5vw, 1.25rem);
}
@media (min-width: 48em) {
.container { display: flex; }
}Ну, то есть, готовый конструктор это, конечно, круто, но надо понимать, что за рамки конструктора выйти или не получится или будет стоить очень дорого. Если делаем что-то типа админок, то ок, а если что-то кастомное, то, кажется, собственная система будет сподручнее.
Кажется они изобрели старый добрый html, который был в 90-е годы. Помните вереницы атрибутов у каждого элемента интерфейса? А потом кто-то придумал CSS и сказал, что эти атрибуты - зло. Сейчас мы к ним вернулись :-D
Да мы к ним регулярно возвращаемся. Вон, тот же Tailwind с utility classes... Не очень мы любим на чужих ошибках учиться
А ведь в итоге это все интерпретируется в браузере в обычный HTML и СSS. Тогда получается, что ваш HTML официально прокачан
xml от них толком не отказывался, а xaml так и вообще выводит из на новый уровень. И мне это нравится не меньше связки html + css
Как бы на вкус и цвет.
А потом мы попадаем на проект, где о реакте и других фреймворках даже не слышали, и начинаем писать старый добрый css)
Своеобразное у вас представление о читаемости и понятности кода. Поседела, пока читала.
Mui просто существует..
После слова Charka перешёл к комментариям)
Поздравляю! Вы открыли ui-киты. Посмотрите на tailwind. И на storybook, если хотите свой кит
Писать х2 кода через пропсы каждого свойства < 1 пропс className с tw стилями
Flutter на минималках
А можно вопрос: что из этого для вас в новинку?
Компоненты библиотеки имеют стили и темы
Компоненты библиотеки имеют встроенную поддержку доступности
Инкапсуляция css
А вот для мне в новинку писать все стили js-ом и пожалуй я не буду так делать.
Может действительно "Хватит пихать CSS в JS"?
С одной стороны — чистый CSS и полная свобода, с другой — Chakra UI и экономия времени. А в центре я, сражаюсь за каждую строку кода и нервничаю одинаково 🙂
Задели за больное, поэтому не могу пройти мимо...
Откровенно страшно было читать тезисы в статье, т.к. сам регулярно занимаюсь разработкой непосредственно UI и прошёл через разные стадии использования всевозможных паттернов и технологий.
1. Избавляемся от стилей.
Вообще вы от них не избавляетесь, а просто выносите на уровень шаблона детальное описание этих самых стилей)
Читаемость? Очень сомнительно... Как показывает мой опыт сокращения со временем только повышают когнитивную нагрузку. Компактность? Да, возможно... за счёт тысяч сокращений и специфичного синтаксиса, которые ещё нужно изучить.
2. Соблюдаем единую стилизацию
Я понимаю что раньше в CSS не было Custom properties и мы все изгалялись как могли, но не в 2025 году же... Сейчас с их помощью можно полностью параметризировать практически всё. В рекламе/статье о Chakra вы могли бы о них хотя бы вспомнить.
3. Встроенная поддержка доступности
Как ни странно, но далеко не всегда это преимущество: бездумное использование заготовок приведёт к ещё большим проблемам доступности, если бы их вовсе не было. Да и некоторые компоненты в различных китах зачастую не дают переопределить важные атрибуты, считая что им виднее.
4. Создаём адаптивный интерфейс
Кажется в первом пункте шла речь о компактности и читаемости... Но на этом пункте она видимо вышла из чата)
Вы боитесь написать больше кода в CSS в угоду компактности? Или отсутствие явных указателей на брейкпоинты это теперь понятность и читаемость? В вашем же примере с CSS всё считывается на раз, не нужны "тайные" знания о брейкпоинтах и не обязательно прописывать одно и тоже значение на каждом из них. Если хочется стандартизации с прицелом на будущее - то возьмите плагин для postcss позволяющий использовать custom properties в media выражениях. Ну или препроцессор в конце концов...
5. Оптимизируем производительность
Tree Shaking и импорт только нужных компонентов - первое заявление с которым согласен: далеко не каждый кит умеет в правильный экспорт "по частям".
Ленивая загрузка стилей - взаимосвязано с первым, но не всегда.
Преимущество перед традиционными подходами - откровенно надуманное сравнение из 2010х. В реальных проектах такого уже давно не видел, может только у зелёных вкатунов.
P.S. пару месяцев назад пытался присмотреться к Chakra, когда выбирал кит для нового проекта, но как раз то о чём написал выше оттолкнуло. Лучше уж посмотреть в сторону shadcn или hero ui если у вас React.
Звучит конечно заманчиво, но главную проблему Chakr вы тактично обошли стороной. В v2 их движок на базе emotion создавал ощутимую нагрузку в рантайме. Если на странице пара сотен таких "удобных" кнопок и инпутов, FPS при рендере заметно проседает, особенно на мобилках.
Сравнение с чистым CSS тоже выглядит сомнительно. В 2025 году никто не пишет простыни CSS вручную, все сидят либо на CSS Modules, либо на Tailwind. Было бы честнее сравнивать именно с ними
Хватит писать CSS с нуля: как Chakra UI экономит время и нервы разработчика