Три UI-фреймворки: порівняння та несподіваний фаворит

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Останнім часом я попрацював із трьома популярними UI-фреймворками, і ось мої висновки. Спойлер: один із них мене справді вразив:

* shadcn (76.8 тис. зірок на GitHub, 94,7 тис. щотижневих завантажень)
* chakraui (38.2 тис. зірок на GitHub, 607.4 тис. щотижневих завантажень)
* daisyui (34.5 тис. зірок на GitHub, 316.8 тис. щотижневих завантажень)

💡 Що сподобалося у shadcn:

* Строгий підхід до структури проєкту: ліба вирішує за тебе, де зберігати UI-компоненти, утиліти, і пропонує стандарти для роботи з Tailwind. Це робить проєкти уніфікованими.
* Крута документація: навіть є стаття, як вирішувати проблему з «—legacy-peer-deps» на останній версії Next.js.

⚠️ Що не сподобалося:

* Бідні або відсутні анімації (натискання кнопок, фокус інпутів тощо).
* Палітра кольорів задається у CSS-файлі, що ускладнює її повторне використання у JS-коді.
* Необхідність конвертувати палітру в специфічний формат 280 25% 10%; (і без ком!). Інакше все ламається.

💡 Що сподобалося у chakraui:

* Назва chakraui звучить потужно.

⚠️ Що не сподобалося:

* «CSS in JS» уповільнює рендеринг у порівнянні з нативним CSS.
* Надлишок кастомних компонентів і заплутана організація стилів ускладнюють підтримку великих проєктів.
* Складний підхід до responsive-дизайну.
* Інтеграція з Framer Motion створює конфлікти: Chakra пріоритизує свої пропси, що обмежує можливості анімацій.

💡 Чому DaisyUI досі мене вражає:

* Багаті анімації компонентів, гнучка темізація й можливість визначати палітру кольорів у JavaScript.
* Нативний та семантичний HTML, що не перевантажує проєкт.
* Лаконічний набір компонентів і простота кастомізації. Наприклад, щоб створити стилізовану кнопку, достатньо додати клас btn. Ніяких кастомних компонентів типу Button для простих задач створювати не потрібно.

Якщо ви використовували ці фреймворки, діліться своїми думками в коментарях. Цікаво дізнатися, чи погоджуєтесь із моїми висновками!

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якщо shadcn дозволяє задавати кольори через sass/scss, то ви можете зробити експорт кольорів через :export { black: $black }, а потім уже в js звертатись до кольорів приблизно так: styles.black.

Стаття звісно шляпа повна, автор полінився навіть лінки на сайти відповідних бібліотек додати.

Дизвподобайка, на переробку
👎👎👎👎👎👎

donate1024.org
зроблений на DaisyUI

Палітра кольорів задається у CSS-файлі, що ускладнює її повторне використання у JS-коді

А можете поділитись як саме ви хочете у js-коді використовувати CSS кольори? Бо шось звучить як «сова на глобус»

Чому DaisyUI досі мене вражає

Мене вражає те, що на M1 Max їх дока з прикладами компонентів безбожно лагає при кожному переході

Реальний приклад: є бібліотека від певного сервісу, яка вбудовує свій попап із своїм дизайном і єдиним офіційним способом для стилізації попапа — це аргументи метода ініціалізації попапа.

І ще недавно в мене були анімації на канвасі, які звісно ж мали бути в дизайн.

Так нічого важкого немає в тому щоб кольори взяти через JS прям із даних сторінки. Щось там аля getComputedProperty

є бібліотека від певного сервісу, яка вбудовує свій попап із своїм дизайном і єдиним офіційним способом для стилізації попапа — це аргументи метода ініціалізації попапа

Це не проблема CSS фреймворків, це проблема тупих девелоперів, котрі не надали API для редагування :) У мене є опенсорс віджет, котрий весь на tailwindcss, але кожен елемент також має BEM класи з логічними іменами. В сумі для кастомізацій є два шляхи:
1) Всі кольори в CSS змінних, їх можна переписати ззовні
2) Всі елементи мають логічні CSS класи, тож можна за їх іменами доповнити стилі

Нащо мені на стороні клієнта додавати калькуляції, якщо експорт змінної стиля відбувається на етапі білда проекта?

І я нічого не писав щодо проблем UI-фоеймворків, я описав реальні задачі, де стає в нагоді експорт стилів до JS.

Нащо мені на стороні клієнта додавати калькуляції, якщо експорт змінної стиля відбувається на етапі білда проекта?

Та я шо знаю які у вас деталі проекту) 99% ліб на стадіі білда проекта кодогенерацію не робить, і ініціалізіція вашої ліби все одно відбудеться на клієнті, де можна getComputedProperty прокинути без проблем. Якщо для вас це не кейс, мої вітання, ви той 0.001% вибагливих юзерів, на кавередж котрих конкретному CSS-фреймворку пофіг :) Хоча я б все одно не брав інший фреймворк чисто через одну js-лібу, якщо звичайно ця ліба не є скелетом вашого проекту

А взагалі, якщо вам треба саме на стадії білда, годинка роботи і експорт можна і самому зробити 😉 Ще й з біндінгами під TS

Про всяк випадок, мова UI-фреймворків не стосується, я писав тільки про факт того, що бувають ситуації, коли добре мати в JS доступ до змінних CSS. І в випадку експорта змінних із SASS/SCSS у JS буде просто набір змінних, а не функція отримання калькульованих стилів, яка ще й відкладе ініціалізацію сервіса до тих пір, поки не будуть прораховані стилі сторінки.

Звичайно, абсолютно інша ситуація, коли ви закладаєте стилі на рівні JS.

Так, я зрозумів, що інколи це треба. І після того як я зрозумів, я також зрозумів, що насправді в js-середовищі досить легко налаштувати експорт змінних в js/ts-файл з будь-якого сорсу. Тому саме цей фактор не має впливати на вибір взагалі ніяк, як на мене :) Без функції калькулювання, а саме кодогенерація на стадії пре-білду.

я хз о чем статья)
ноль норм сравнения: вес, функции, совместимость? Я думаю если в жпт закинуть — будет намного больше полезной инфы.

Сами либы:
Чакра — плохая либа, с кучей багов которые не фиксятся годами
Остальные 2 — ноунеймы

Двічі написали про плюси shadcn.
Так який фреймворк вразив, який сподобався найбільше?

пропоную перечитати ще раз текст

Підписатись на коментарі