Să-mi explice cineva ce e cu popularitatea la prostia aia de tailwind.
Băi mi-a predat cineva un html de implementat făcut in tailwind și n-am știut că există așa ceva. Bine, spre apărarea mea mi s-a spus explicit că nu se folosește nici un framework e raw css.
I-am zis la ăla că ce amator i-a făcut designul sunt mii de clase aici, orice modific totul explodează, e mai fragil decât o bombă chinezească.
Apoi îmi zice că de fapt e un framework acolo, și că e tailwind css.
Dau să caut…ai de capul meu cine a avut ideea asta stupidă?
De ce să înveți css când poți face o clasă pentru fiecare instrucțiune css? După ce ani de zile și sute de frameworkuri care au scos codul css inline vine ăsta și îl bagă înapoi!
Îmi poate explica cineva diferența între inline css și tailwind?
Mi s-a zis că acuma toată lumea folosește componente (react, vue, etc) și mentenanța la așa ceva nu mai e problemă că măcar sunt separate pe componente…
Abominație cred că e un compliment pentru mizeria asta.
Practic pot face și eu așa ceva doar luând toate instrucțiunile css și le convertesc in clase.
Nu știu cine e ăla dar ar merita prins la colț de niște developeri și bătut bine golănește :))
Toate clasele alea se suprascriu, se repetă, mentenanța devine un coșmar, nu. e lizibil, pe lângă că am învățat pe de rost toate instrucțiunile css acuma trebuie să învăț și clasele lu’ ăsta ca să fiu productiv?
Noroc cu phpstorm că dădeam click pe clasă și mă ducea la definiția ei. Dar trebuia cu o grămadă să fac așa până să înțeleg ce și cum…
Chiar m-ai facut curios, o sa incerc sa-l folosesc si eu sa vad care e treaba cu el. Doar din ce am citit, mie mi s-a parut ca se bazeaza foarte mult pe Atomic Design Principles Atomic Design | Atomic Design by Brad Frost , chestie veche de acum 5 ani scos de Brad Frost pe care il urmaream.
Dar daca se ajunge sa suprascrii text-white sa fie verde e fail complet. Teoretic nu ar trebui sa fie nevoie.
Crezi tu că search/replace în 150 fișiere[1] este o idee mai bună decât search/replace într-un singur fișier css?
Eu zic de schimbări în timp, nu la prototipare, când i se pare clientului (sau omului de la UI/UX) că butoanele alea verzi ar trebui să fie mai albastre, font-urile ar trebui să fie cu 0.01rem mai mari iar titlurile să aibă border șamd.
În loc să ai un singur loc de search/replace, te apuci să cauți în toate componentele și template-urile proiectului.
Tailwind este o idee buna cand livrezi exclusiv componente si aplicatia e facuta din componente.
Fiecare componenta are un stil/componenta si un stil din context. E mult mai practic sa ai stilul in JSX/CSS per componenta decat pe toata aplicatia.
Asta inseamna ca poti refolosi componentele in total alte aplicatii/mobile fara sa te temi ca trebuie sa iei CSS dintr-un loc in altul.
La o aplicatie mare nu te apuci sa schimbi stilul din CSS doar asa, ca poate strici feature-uri pe care lucreaza alte echipe, trebuie sa te limitezi exact la componentele tale. Eventual se creeaza un design system in care se seteaza un numar fix de marimi si culori si doar pe alea le folosesti in toata aplicatia (ori intr-un fisier SCSS cu variabile la nivel global, ori cu clase din tailwind), nimic altceva. Iar clientul nu o sa iti zica alta culoare, designerul o sa lucreze cu paleta lui de culori si size-uri pe care o folosesti cu tailwind.
Eu am avut la fel multe probleme cu fisiere SCSS care importa variabilele de size, culorile dintr-un pachet NPM. Cand creezi o componenta noua niciodata nu stii de unde sa importi si unde sa precizezi fisierul scss ca sa fie compilat bine… Iar la IE conteaza ordinea. Cu tailwind scrii class=“bg-red-500 w-32” ca asa e in design si ai rezolvat treaba.
Nu folositi @apply in CSS, folositi direct clasele in HTML/JSX, tailwind nu mai are nici un sens daca nu il folositi in HTML.
Teoretic la componente pastrezi principiile SOLID, deci o data creat nu il mai modifici sau daca trebuie modificat extinzi componenta. Adica asta inseamna sa faci alta componenta in care ii dai alta tema la componenta deja existenta.
pai mx-5 e ceva batut in cuie, nu modifici ce inseamna mx-5 veci
folosesc tailwind pe proiect, nu sunt tare incantat de el da asa pe moment as zice ca unul dintre avantaje e ca nu trebuie sa-ti bati capu cu nume de clasa
gen BEM cu container apoi container__item si alte cacaturi
de asemenea mi se pare eleganta implementarea de variants cu breakpoints, de ex mx-5 md:mx-8 lg:mx-10
Cu asta sunt de acord, un buton nu ar trebui sa fie atat de “spart” in clase de html, ci mai degraba sa existe 2-3 variante de butoane, pe care le customizezi din CSS si se propaga global.
Dar din cate am inteles, poti crea si in Tailwind un fel de “presets” ?
Ex.:
Padding-ul unui button nu are ce sa caute in alte clase de html.
Marginea unui buton ar trebui sa fie separata in alte clase de html.
Pentru ca:
Button-ul trebuie sa arate consistent, fie ca e button-sm, button-lg.
Distanta dintre un buton si un alt element pe o pagina variaza si nu ar trebui incastrata in clasa butonului.
Analogie:
Ai doua noptiere langa pat care trebuie sa arate la fel, sa fie simetrice.
Spatiul din jurul noptierelor poate varia doar in stanga din cauza unui alt obiect.
Cam asta cred ca rezolva Tailwind cu aceste clase sparte.
Spatierile de gen margin/padding gen 1,2,3,4,5 etc. ar trebui sa urmeze o scara hierarhica, ca sa stabilesti un ritm, sub nici o forma nu modifici valoarea mx-5. Folosesti 4 sau 6, iar daca nu-ti este de ajuns, ai pornit gresit de la inceput.
Nu sunt neaparat pro pentru tailwind. Cum zici si tu css modules, styled components sau in special svelte cu css in <style></style> sunt optiuni mai elegante si mai framework-less. Iar dupa cum stim framework-urile vin si se duc.
Dar se poate folosi tailwind ca sa faci ceva rapid, se poate combina tailwind cu styled-components sau oricum daca ai css conditional cu classnames sau clsx (foarte comun in react) atunci si tailwind o sa arate mai clar.
sau te limitezi si folosesti tailwind doar pentru componente simple/structura si unde ai nevoie de hardcore css introduci styled components sau css modules.
Single responsibility cu clonarea Input-ului cand vrei sa fie cu border mov:
const PurpleInput = tw(Input)`border-purple-500`
Aysun vezi ca si la tailwind ai variante si preset-uri ca sa extinzi/schimbi default-urile, e destul de complex, chiar ai de invatat ceva cu el. Dar daca ar fi sa compari un design system ca si Ant Design cu ceva componente care folosesc Tailwind sau cu un design system intern care are o echipa dedicata cu canal de slack pentru intrebari in loc de documentatie cred ca ai alege tailwind.
Sau stai sa vezi ce discutii atrage in design system propriu BEM cu SCSS compilat global cu un SCSS luat din fiecare componenta in parte. Poti sa strici tot design system-ul daca uiti/nu stii sa prefixezi ceva cum trebuie si testele e2e nu sunt facute sa verifice acest lucru. Doar visual testing-ul poate verifica bug-urile cauzate de ceva incorect din BEM si e un cosmar de intretinut.
Mie personal imi place tailwind, o sa enumar cateva din motive:
are scale definite pentru marimi si culori, pe care pot sa le editezi daca vrei; nu mai stai sa pui totul pixel perfect, folosesti dimensiuni prestabilite
dupa cum au spus si adeptii framework-urilor de css gen tailwind, de multe ori am incercat sa fac conexiuni trase de par cu BEM si metodologii similare
cand ma uit pe cod scris cu tailwind stiu exact la ce sa ma astept, nu mai trebuie sa umblu pe nu stiu unde sa vad care-i treaba
este foarte fain cand faci prototyping, schimbi numele unei clase in browser si vezi direct ce se intampla → apoi iei HTML-ul cu copy paste si aia e
exista multe resurse faine legate de Tailwind daca cauti inspiratie, inclusiv TailwindUI (comercial)
Înțeleg flexibilitatea și portabilitatea când discutăm de un proiect bazat pe componente gen react/vue/etc. Dar fix aceeaș portabilitate ai avea-o dacă ai face inline css cu style="" peste tot.
Da, oferă un layer de abstracție, dar nu întotdeauna asta e un avantaj. De exemplu pentru mine debugging-ul e un coșmar pentru că sunt clase peste clase care interacționează una cu alta de la parent,child, pe tot lanțul, și trebuie să aflu care îmi generează problema în contextul respectiv. Poate fi și ceva gen 1px mai la dreapta/stânga, dar eu le observ și mă disperă
asta si intr-un fisier scss ar ocupa mai multe randuri si ar veni nestuit intr-un selector hidos de min width. Cu tailwind se rezolva in 2 cuvinte.
Odata ce iti intra in mana lucrul cu tailwind modifici rapid stilu la orice chestie, nu sapi in fisiere scss si te gandesti oare pe ce elemente se aplica stilu asta, unde e folosita clasa asta etc.
Vezi divu direct in template, vezi toata ierarhia. Ah divu asta exterior are mx-5? Pai ar trebui sa fie mx-2. Una doua ai schimbat. Nu sapi dupa clasa de “container__subelement–paaded” in alt fisier.
De acord ca e gandit mai mult pentru frameworkuri component based, deoarece e incurajat sa creezi cat mai putine clase generale care sa se aplice pe toata aplicatia.
Parerea mea e ca e fundamental gresit sa folosesti numele culorii in numele clasei. Tentant dar gresit. De aia bootstrap e elegant si foarte folosit, pentru ca asa e bine: partea de programare trebuie separata de cea subiectiva/culori, adica “primary” in loc de “verde-galbui-cu-umbra-albastra”