Esmu cilvēks, kura tiešie darba pienākumi īsti nepaģēr nodarboties ar weba lietām, bet tā visa padarīšana gribot negribot visu šo gadu laikā ir kļuvusi par vai nu neatņemamu dzīves sastāvdaļu, vai arī sirdslietu - neesmu vēl izlēmis. Tāpēc arī nevaru neturpināt vismaz iepazīties, ja ne pielietot lietas, kas ir gana stabilas un populāras. Tas nenozīmē kļūt par adeptu, bet būt informētam un grāmatu lasījušam.

Šajās garajās brīvdienās kārta pienāca Tailwind (tā oficiālais nosaukums gan ir Tailwind CSS, bet man slinkums visu laiku tos trīs drukātos burtus rakstīt). Galvenokārt tamdēļ, ka ekosistēmā, kurā pats esmu, tas tiek stumts iekšā pa visiem pieklājīgiem un nepieklājīgiem galiem kā jaunais melnais, kā panaceja visam, kā vienīgais noklusētais pareizais, kā svētais grāls. Tas mani allaž dara skeptisku, jo ir kaut kāda nedaudz automātiska pretestība.

Lasot šo visu, nedrīkst aizmirst, ka es tikai parotaļājos un tiku galā ar vienu triviālu projektiņu. Šo nevar uzskatīt par utility-first pasaulē kārtīgi padzīvojuša eksperta viedokli.

Kā blakusdomu, nedrīkst nepieminēt JSS, kas kļūst par de facto standartu React pasaulē un ir pavisam cita ballīte. Tai vēl neesmu saņēmies drosmi, jo React vietā man visur ir Vue un React, tāpat kā Angular un daudzie mazie brāļi, man ir tikai "esi lietas kursā, ja vajag" plauktiņā.

Tailwind ir utility-first tipa CSS freimworks. Pamatideja - neraksti semantiskas klases. Tas nav liegts, bet nav arī spiesta lieta. Viss, ko tu dari, ir kaut kas šāds:

<div class="min-h-screen bg-gray-100 py-6 flex flex-col justify-center sm:py-12">
    <div class="relative py-3 sm:max-w-xl sm:mx-auto">
        <div
            class="absolute inset-0 bg-gradient-to-r from-cyan-400 to-sky-500 shadow-lg transform -skew-y-6 sm:skew-y-0 sm:-rotate-6 sm:rounded-3xl">
        </div>
        <div class="relative px-4 py-10 bg-white shadow-lg sm:rounded-3xl sm:p-20">
            <div class="max-w-md mx-auto">...</div>
        </div>
    </div>
</div>

Pirmajā, otrajā, un pat deviņdesmit devītajā mirklī izskatās briesmīgi, ne? Aizvien neesmu fans, bet redzu arī to, ka kādam var patikt, var būt noderīgs un var iekļauties kopējā komandas izstrādes ciklā.

Idejiski modernas aplikācijas sastāv no komponentēm. Šajā gadījumā viss vairāk vai mazāk nostājas labākās vietās, nekā iepriekš, jo visa šī ballīte tiek sadalīta daļās un elementi var tikt atkalizmantoti. To gan klasiskajā piegājienā dara ar scoping vai BEM. Lai gan, ar utility-first piegājienu varētu būt dramatiska nepieciešamība visus HTML elementus, kurus var komponentizēt, izcelt atsevišķās kompoenentēs, un tas jau ir neganti...

Vēl var iekš Tailwind arī imitēt veco labo CSS piegājienu ar semantiskām, klasēm, bet tas atkal jau ir nedaudz hacky:

/* Trivializēts piemērs */
.mzgd {
    @apply .font-bold .py-2 .px-4 .rounded;
    border-color: red;
}

Skaisti, ne? Ja vēlies, sāc ar prototipēšanu inline un beidz ar šādu semantiskāku pieeju, ja vēlies. Bet tas brīdis, protams, nekad nepienāks, kā vairumam atlikta refaktoringa, ja viss strādā tāpat.

Protams, ka Tailwind paģēr arī iepazīties ar jaunu CSS pre nē, bet postprocessoru - PostCSS.

OK. Tas viss izskatās pēc inline CSS definīcijām. Lai gan skapis, no kura iznākt, ir stipri dziļāks (tipa, Nārnijas un vēl kāda reference).

Jāatzīst, ka pliku CSS neviens vairs neraksta, ja nu vienīgi maziem projektiem vai arī tad, ja esi riktīgi hardcore vai arī nevēlies apgūt neko jaunu un "vispār šitā visa jaunā tendence ar miljards atkarībām un tūlingiem parastam webam ir nāves smaka". Tiek izmantoti preprocesori (tas pats Sass, piemēram).

Ko ļauj utility-first? Ātri (tiešām ātri) prototipēt. Kā jau visos bezgalīgi daudzajos video - sāc ar padding, margin, fonta izmēriem, krāsām, izkārtojumu. Viss izskatās diezgan smuki. Lai gan man, darot to pašu, viss izskatās tieši tāpat kā iepriekš - pēc mēsla, jo nerubīju dizainu :)

Salīdzināt ar inline CSS īsti nevar, jo utility-first ļauj izmantot inline arī pseidoklases (:hover), media breikpointus, sarežģītākus selektorus (.class ~ * {}), utt.

Tailwind ļauj aizmirst par izskata un satura nodalīšanu, nedomāt par semantiku, ļauj aizmirst par daudz lietām, kuras būtu jāzin. Tiek upurēts ļoti daudz kas no līdz šim par aksiomām uzskatītā. Ieskaitot gadu desmitiem ierastos un uzlabotos veidus kā darīt lietas. Tas nenozīmē, ka slikti. Tas gan arī nenozīmē, ka labi.

Lielākos projektos šis gan var izgāzties, ja nav strikta procesa no dizaina līdz realizācijai. Un būsim godīgi - cik daudz projektus zini, kur tāds ir vispār? :) Vizuālā daļa diezgan veikli var kļūt nepārskatāma un neuzturama.

Teorētiski vēl viena lieta ir tā, ka līdz ar utility-first freimworka adoptēšanu, pienāk beigas. Tu esi piesiets šim piegājienam. Lielākos projektos no tā aiziet būs ilgi, dārgi un sarežģīti.

Migrācija no preprocesoriem vai pat plika CSS uz Tailwind ir iespējama, bet nav nekāds rožu dārzs. Tā gan ir problēma jebkurā fundamentālā migrācijā.

Diezgan nopietns ir fakts, ka pārejot uz utility-first tu pazaudēsi daudz no tiešām noderīgā - kaskādi, specificity, utt. Var kombinēt ar parastu CSS, bet tas jau būs ne pārāk baudāms hibrīds.

Piemēram, ja esi definējis ko šādu, tad inlainā ar to pašu utility-first piegājienu nomainīt atsevišķiem .status header a elementiem krāsu uz citu būs jāpacīnās:

.status header a {
    @apply text-black no-underline;
}

Vēl jau neesam parunājuši par Tailwind JIT kompilatoru, PostCSS purge, kas var negaidīti ievest diezgan sarežģīti navigējamā meža biezoknī, un citām lietām, kuras ir jāapgūst un jāpielieto.

Starp citu. Lai gan tas automātiski nenozīmē, ka tā ir milzu problēma, taču ir vērts pieminēt, ka Tailwind tomēr ir kļuvis par daudzmiljonu biznesu. Tas ļauj veltīt nopietnu resursu tā popularizēšanai (mārketings un lobiji) un izstrādei (bezieņēmumu vai mazieņēmumu atvērtais kods noskatās). Un, protams, apkārt veidojas ekosistēma. Utility-first ir daudz lietu, kuras var uzlabot, vienkāršot, piepārdot.

Tailwind iespēra pa kņudekli tieši tanīs vietās, kuras sāpēja. Tas deva iespēju darīt daudz ko tik tiešām ātri, popularizētāji demonstrēja to, cik vienkārši ir radīt smukumu (kas, kā izrādās, nebūt nav vienkārši, ja nejēdz). Ekosistēma ap utility-first izauga principā vienas nakts laikā. Utility-first izslēdza kontekstu pārslēgšanu - lēkāšanu starp HTML rakstīšanu un CSS/dokumenta struktūru.

Tad kā tur ir - kill, marry or date? Noteikti date. Piegājiens nav ignorējams, jo tas ir nozīmīgs. Lietot nav oligāti. Nelietot arī. Ir savi plusi, bet ir savi mīnusi. Kā jau visam. Tipisks "jā nu nē".

Ja runa ir par komandu, tad te ir jāpieiet ļoti uzmanīgi. Piemērotākais termins, kurš nāk prātā, ir no pārmaiņu vadības mantrām - paradigm shift. Visiem ir jābūt vienā laivā, ir nepieciešams grūmings, jāformalizē un jāadaptē dizaina process, visiem ir jāmācās, jāpraktizē, utt. Šis nav viena cilvēka lēmums. Vismaz ne demokrātiskā komandā. Migrēt un tad jau redzēs piegājiens nederēs. Pāreja uz utility-first var radīt nevajadzīgu spriedzi, jo ir ļoti pretrunīga pieeja. Un arī atpakaļceļš, ja nu tas jāveic, būs ļoti sarežģīts.