Ce parere aveti despre Tailwind CSS? Eu personal l-am folosit pentru doua proiecte, si mi se pare ca approach-ul utility-first poate fi mult mai rapid daca e nevoie sa transpui un design in web.
Am inceput sa scriu si o serie de topic-uri despre Tailwind CSS la noi la firma:
Comparativ cu Bootstrap e un approach diferit, in sensul ca ideea nu e sa fie componente prestabilite, ci sa iti fie mai usor sa faci componente de la zero cu clase de utilitate, gen padding, margin, font size etc.
Se potrivește cu react.
Eu folosesc Otion la un mini proiect acum care e inspirat din tailwind. E frumos dacă nu e nevoie de un design system.
Tailwind si Ant design sunt cele mai bune opțiuni pentru react acum. Un design system îți trebuie doar dacă pui tot css-ul intr-un repo și un pachet npm ca să poată fi reutilizabil în mai multe proiecte. Asta presupune și o echipă dedicată de UI.
Tailwind are și tailwind ui, adică componente tailwind ușor de integrat.
Nu are sens în html/php, are foarte mult sens dacă îți legi stilul de componenta care n-are nevoie de stil separat. BEM oricum presupune să ai o clasă separată per componenta, dacă e oricum unică de ce vrei sa o scoți intr-un alt fișier ? Practic nu ai voie să o refolosesti.
Oricum îți poți trimite o temă în props ca să faci culorile globale, dar majoritatea css-ului îl faci pe componenta și nu iti trebuie css global dacă trimiți o temă de mai sus.
fix de’asta nu-mi place nici mie Bootstrap. Tailwind seamana ca sintaxa, css inline. E mult mai ok sa ai niste elemente definite pe care sa-ti aplici tu stiluri proprii. Eu folosesc Material (pentru Angular), e saracacios in culori, dar tocmai de’asta e placut, nu trebuie sa stii pe de rost (col-lg-2), si sa aplici o lista de clase pe acelasi atribut.
Cred ca la sfarsitul zilei sunt doar niste tool-uri cu metode diferite de workflow.
In schimb as spune ca design-ul initial si design system-ul pus la punct de catre un designer conteaza mult mai mult.
Ce vreau sa spun este ca un designer bun ar trebui sa stie sa creeze un sistem de culori, spatiere, typography astfel incat developer-ul sa nu-si bata mult capul. Chiar si la introducerea unor componente noi, un designer bun ar trebui sa stie cum sa le creeze astfel incat sa nu agite apele.
Asadar se ajunge in stadiul in care dezvolti pagini doar in html, adaugand clasele necesare, fara sa te mai atingi de CSS. 90% din pagini sunt spatiere si culori prestabilite.
Tailwind e atat de fragmentat incat poti crea design-ul on the go de catre developer direct, desi nu vad unde e asta util, decat atunci cand vrei sa creezi niste prototipuri rapide.
Intr-un UI bun si consistent nu ai motive pentru care sa existe 4 tipuri de butoane, unul cu text-dark, altul cu text-darker. Acolo e de vina designer-ul, nu developer-ul.
si css-ul e fragmentat. nu vad de ce ar trebui sa invat ce clase imi dau padding 10 cand as putea scrie direct inline padding:10px. si fii antena, e mai usor de scris padding: 5 10 decat py-10, px-5,
La un design bun nu mai scrii 5 10 ci pui o variabila * valoare pe scara ierarhica.
padding: 5 10px; devine padding: $base * 1.33 $base * 1.66 . Iti place sau nu, asa ai control global al design-ului. Si de ce sa mai scrii toata polologhia aia cand poti pune py-1 px-2.
Cand vine designer-ul si iti spune in mijlocul proiectului ca trebuie sa micsoram scara modulara, o sa faci find and replace la padding: 5 10 inline, in loc sa schimbi o variabila.
Un design bun e consistent, daca ai pus padding 10px la un button si 12px la altul, deja poti sa spui papa la design ca esti pe alte carari.
pentru un design consistent o filozofie de genul tailwind chiar nu-si are sensul. de ce as vrea sa am un buton cu 40 de clase cand pot avea o singura clasa care sa defineasca marea majoriate a proprietatilor?
isi are sens exact in momenul in care ai un buton cu padding 5 si altul cu padding 10. sau cand esti contorizat in linii de cod scrise.
Pai de acord cu tine, asta si ziceam, nu ii vad rostul decat daca ai nevoie de ceva rapid sau nu exista designer, dar asta nu inseamna ca e la fel ca CSS inline. CSS inline nu e scalabil, e greu de controlat si foarte predispus la dezastre si dead-ends.
tocmai ca in ux exista exemplul clasic in care pe o pagina poti avea un call-to-action si mai multe actiuni secundare, care trebuie sa arate similar (sa fie evident ca toate sunt actionabile), insa doar unul dintre acestea este actiunea principala
Da, dar din punct de vedere ierarhic nu sunt aceleasi butoane. Ai buton de submit sau primary, secundar si daca esti intr-un webapp, deja treci si la tertiar lejer.
Ele sunt butoane separate, nu prea are sens sa ai 7 clase la fel si doar 1 sa difere la fiecare. Pana si un buton link are nevoie de un padding invizibil ca sa se alinieze singur langa un cta primar + ca aduce si beneficii la accesibility.
Ce voiam eu sa spun e ca 4 butoane primary, din care unul cu text dark si altul darker, e dezastru dpdv UI, dar Tailwind iti permite usor sa creezi asta.
button button-primary,button button-cancel, button button-etc. prima clasa e definitia de baza a butonului, a 2-a sunt exact acele proprietatie extra. tot nu se justifica tailwindul. gandeste-te ca designerul se gandeste sa puna border-radius pe toate cele 1234 de butoane. ce faci? search and replace? sau modifici clasa de baza si-i adaugi noua proprietate?
Mi se pare o reîntoarcere la stiluri inline, dar hei, acum le numim utility classes . E mult mai bine.
si fii antena, e mai usor de scris padding: 5 10 decat py-10, px-5,
Cu diferenta ca aici ai parte de cache si responsive, lucruri ce nu le obtii cu stiluri inline. Nu mai vorbim de consistenta in spatieri/culori/dimensiuni. Si da, eu scriu mai repede/usor “py-5” decat “padding: 1.25rem 0;”.
nu vad de ce ar trebui sa invat ce clase…
Nu trebuie. Daca treci prin docs 15 minute si sti css n-ar trebui sa ai probleme + ca exista o extensie IntelliSense pt VSCode.
de ce as vrea sa am un buton cu 40 de clase cand pot avea o singura clasa care sa defineasca marea majoriate a proprietatilor?
gandeste-te ca designerul se gandeste sa puna border-radius pe toate cele 1234 de butoane. ce faci?
Daca ai componente ui bine definite le extragi [1] iar daca folosesti react/vue/co. modifici doar intr-un loc.
Sunt multe de zis, va invit sa-i cititi documentatia si sa va jucati real putin cu el. Personal am observat o crestere de productivitate, mentenanta e mult mai placuta si incrementarile de design sunt o placere. Ideea nu-i noua, tata lor e tachyons.
Asta nu prea am mai auzit, par lucruri din alea inventate pt marketing, gen limbajul ala e mai rapid cu 40%, cum am observat asta, rulat niste loop-uri de 10 mii or si intr-un caz e 1 milisecunda, altul 0.6 millsecunda… gata ditamai titul de marketing.
Cache nu ai in stiluri inline pentru ca e un singur fisier care contine si datele si stilurile, iar daca datele sunt dinamice inseamna ca nu poti cache-ui fisierul.
Responsive nu ai in stiluri inline pentru ca nu poti pune media queries inline, ele se aplica pe clase.
To each his own, fiecare are alte prioritati intre:
cod ca la carte
cod usor de folosit
cod flexibil
cod usor de intretinut
Asta in the real world, ca altfel se poate discuta oricat intre () => {} si function() {} si diferentele dintre ele.
Mi s-a parut interesant cand l-am descoperit [cred ca datorita postului lui Ionut], dar nu destul de interesant cat sa fie o prioritate. Din ce tin minte parea bun pentru chestii rapide daca stii deja sa lucrezi cu el, altfel nu cred ca as sta sa invat numele claselor si prescurtari fix cand e ceva urgent. Merge si cu style, inca e suportat de toate browser-ele.
Tool-urile de genul n-au fost nici macar dezvoltate pentru programator, au fost dezvoltate cu ideea de a automatiza crearea unui layout si stilizarea cu generatoare de cod.
Cu tailwind eu imi imaginez ca e mai simplu sa faci un generator dupa un design si invers.
Se ridica problema de restilizare cand stilul e inline. Eu zic ca daca poti deschide fiecare componenta intr-un editor vizual si schimba valorile de acolo nu cred ca ai nevoie sa faci asta din cod. Eventual te joci putin in devtools, salvezi un snapshot la numele claselor/componenta si il importi in proiect undeva.
