Despre Tailwind CSS

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…

Mie mi se pare o abominație.

E popular doar pentru că e împins de Wathan, altfel ar râde și curcile de idee.

Chiar am încercat să-l folosesc la proiectul curent, să intru în mindset-ul lui, dar este abysmal:

  • pentru a-l folosi în html este nevoie să repeți o grămadă de reguli.
  • poți ajunge LEJER la clase mincinoase [1]
  • pentru a-l extrage în clase/componente este nevoie de niște gimnastică mentală demnă de olimpiadă [2].

Salvezi 5 linii de cod în detrimentul unui cod lizibil.

Repet ce am mai zis: ar putea fi util în cazul în care vrei ceva să faci un prototip fără să-ți pese prea mult de altceva.


[1]:

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-500 hover:bg-green-700">

Poți suprascrie culorile, astfel încât text-white să fie verde iar bg-green să fie rosu. Mișto!


[2]:

.btn {
    @apply py-2 px-4 font-semibold rounded-lg shadow-md;
}

în loc de:

.btn {
  padding: 2px 4px;
  font-weight: 600;
}

@media (min-width:XX) { .btn { box-shadow...} }
@media (min-width:YY) { .btn { border-radius... } }

S-a mai discutat pe forum despre el:

2 Likes

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…

1 Like

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.

Păi sunt doar clase, iar clasele sunt aplicate în ordine. Ultima clasă va fi cea care rămâne.

Apropo există cineva care se pricepe la tailwind și mă poate ajuta contra cost să rezolv o problemă la proiectul ăla? :))

Nu e responsive corect pe ipad în landacape.

Cum să nu fie nevoie? Ai o culoare, vrei să o schimbi cu altă culoare. Nu cred că sunt singurul care a avut nevoie de un asemenea… feature :smiley:

Atomic Design este o idee infinit mai bună decât tailwind.

Pai scrii text-green in loc de text-white si ai rezolvat problema.

1 Like

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.

Nu reiau absurditatea din spatele acestei idei…


  1. Sau 5 fișiere, sau 10, sau 2. > 1 cum ar veni. ↩︎

1 Like

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.

3 Likes

Știi cum poți face stiluri pe componente? Cu module!

import styles from 'my.module.scss`

return <div className={styles.awesomeDiv}></div>

Perfect izolat, numai bun de distribuit.

Hai să comparăm abominația acum:

return <div className="mx-5 my-10 border-1 border border-solid border-gray-500">

Cum este cârnatul ăsta mai SOLID decât prima variantă?

Cum îndeplinește tailwind single responsability dacă schimbarea lui mx-5 va afecta absolut tot ce folosește clasa aia?

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

2 Likes

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:

  1. Button-ul trebuie sa arate consistent, fie ca e button-sm, button-lg.
  2. Distanta dintre un buton si un alt element pe o pagina variaza si nu ar trebui incastrata in clasa butonului.

Analogie:

  1. Ai doua noptiere langa pat care trebuie sa arate la fel, sa fie simetrice.
  2. 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.

1 Like

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.

E.g tailwind cu classnames:

const bordered = false;
const btnClass = classNames(
 'mx-5',
 'my-10',
 'border-1', 
 {'border': bordered},
 'border-solid',
 'border-gray-500'
);
return <button className={btnClass}>

sau te limitezi si folosesti tailwind doar pentru componente simple/structura si unde ai nevoie de hardcore css introduci styled components sau css modules.

Mai exista si asa ceva, tailwind macro.

import tw, { css } from 'twin.macro'

const hoverStyles = css`
  &:hover {
    ${tw`text-black`}
  }
`

const stylesInput = ({ hasHover }) => [
    tw`border` // Add base styles first,
    hasHover && hoverStyles // Then conditional styles
]

const Input = props => <input css={stylesInput(props)} />

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.

2 Likes

Mie personal imi place tailwind, o sa enumar cateva din motive:

  1. 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

  2. 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

  3. 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

  4. 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

  5. exista multe resurse faine legate de Tailwind daca cauti inspiratie, inclusiv TailwindUI (comercial)

3 Likes

Î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ă :slight_smile:

1 Like

cu inline style nu ai variants, de exemplu

nu poti zice bg-white lg:bg-red-600

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.

3 Likes

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”

4 Likes

Se pot seta propriile culori si denumiri:

scopul este ca definedti o singura data culoarea intr-un json si apoi se genereaza clase pentru orice poate folosi culoarea

o sai ai text-albastru-verzui bg-albastru-verzui border-albastru-verzui etc

dupa aia poti ajusta culoarea albastru verzui in json si se reflecta absolut oriunde este folosit, ca si o variabila scss