Ha az elmúlt években követted a frontend trendeket, biztosan belefutottál a Tailwind CSS névbe – és nem véletlenül vált a fejlesztők új kedvencévé.
A Tailwind CSS egy modern, utility-first (segédosztály-alapú) CSS keretrendszer, amit arra terveztek, hogy elképesztő gyorsasággal lehessen vele egyedi webes felületeket építeni.
Szemben a hagyományos CSS keretrendszerekkel (mint például a Bootstrap), a Tailwind nem ad előre elkészített komponenseket (gombokat, kártyákat, navigációs sávokat). Ehelyett apró, egy-egy konkrét stílusfeladatért felelős osztályokat (utility classes) biztosít, amiket közvetlenül a HTML-kódban kombinálhatsz.
Interjú Bánkuti Gáborral: A LEGO-elvtől az AI-ig
Ahhoz, hogy pontos képet kapjunk a keretrendszer gyakorlati előnyeiről, érdemes megnézni, hogyan működik a dolog a való életben, éles ügyfélprojekteken.
Megkérdeztünk egy profi webfejlesztő freelancert, Bánkuti Gábort, hogy ő személy szerint miért használ ma már szinte kizárólag Tailwind CSS-t a munkái során:
Marcell: A Tailwind CSS-ről rengeteget lehet olvasni, és persze a mesterséges intelligenciát is meg lehet kérdezni az előnyeiről. Engem viszont inkább az érdekel, hogy te személy szerint miért szeretsz ebben dolgozni?
Gábor: Van egy kis önelégült örömöm ezzel kapcsolatban. Amikor a 3-as verzió még csak béta állapotban volt, és szinte mindenki fújt a Tailwindre, én már mondtam, hogy ez lesz a jövő. Az összes fejlesztő haverom azt hatogatta, hogy „ez mekkora hülyeség” – ma pedig szinte mindegyikük ezt használja.
Marcell: De miért? Mi az oka annak, hogy szerinted ennyire bevált?
Gábor: Szerintem azért, mert frontend fejlesztés közben valójában ugyanúgy algoritmizálsz, mint a backenden. Ott az üzleti logikát teszed rendbe, frontenden viszont a vizuális elemeket. Amikor elkészítesz egy gombot, nem egyetlen elemet tervezel, hanem egy teljes rendszert (design systemet). Van primary, secondary, kitöltött, keretes, kis és nagy méretű, ikonos vagy épp nyilas változat. Ha ez a rendszer jól van megtervezve, akkor egy új oldalt már nem nulláról építesz fel, hanem a meglévő LEGO-elemekből rakod össze.
Marcell: Ez kicsit olyan, mint az objektumorientált programozásban egy osztály különböző példányai.
Gábor: Pontosan. Egy rossz frontend fejlesztő egyszerűen felülről lefelé lekódolja a weboldalt. Egy jó szakember viszont először felépíti ezt a dizájnrendszert. Ha ez kész van, utána egy új landing page-et akár fél óra alatt össze lehet rakni a meglévő komponensekből.
Marcell: Jó, de ezt hagyományos CSS-ben is meg lehet csinálni.
Gábor: Meg, de sokkal nehézkesebben. Régen az volt az általános szemlélet, hogy külön fájlban van a HTML, a CSS és a JavaScript – ez volt a klasszikus feladatkörök szétválasztása (Separation of Concerns). A React ezen radikálisan változtatott: azt mondta, hogy egy komponenshez tartozzon együtt a struktúra, a logika és minden más. Szerintem ennek a következő természetes lépése volt a Tailwind.
Korábban minden elemhez egyedi osztályneveket kellett kitalálni: button, button-container, button-label, majd ezeket egy másik fájlban megkeresni és stílusozni. Elméletben ezek újrafelhasználhatók voltak, a gyakorlatban viszont nem. Egy év múlva már te sem emlékszel, melyik név mire szolgált. Ha pedig ugyanazt az osztályt több helyen használtad, egyetlen módosítással könnyen elronthattál valami mást az oldalon. Emiatt végül mindenki inkább létrehozott egy újabb és újabb osztályt.
Marcell: Ebbe a káoszba én is belefutottam már.
Gábor: Na, a Tailwind ezt a problémát teljesen megszünteti. Nem kell neveket kitalálni, egyszerűen odaírod a HTML-be, hogy class="flex p-4", és rögtön látod, hogy ez egy flexbox, négyes paddinggel. Nem kell másik fájlba ugrálni, sem fejben tartani a neveket. Maga a HTML mondja el a stílust.
Marcell: Viszont ha egy gombon tíz különböző stílus van, akkor azt mindig újra le kell írni az oldalakon?
Gábor: Modern keretrendszerekben, például Reactben nem. Ott egyszer elkészíted a Button komponenst, és mindenhol azt használod újra, a tulajdonságait (propjait) változtatva mondod meg neki, hogy kék vagy zöld legyen. A Tailwind ebben csak annyit változtat, hogy magát a komponens belső kódolását teszi sokkal egyszerűbbé. Ha pedig nagyon szeretnéd, itt is létrehozhatsz globális osztályokat, nem tiltja meg semmi – egyszerűen a legtöbb esetben nincs rá szükség.
Marcell: Tehát lényegesen kevesebb egyedi CSS-t kell írni.
Gábor: Pontosan. A legtöbb dobozra (div) általában ugyanazok a tulajdonságok kerülnek: flex, padding, margin, gap. A gyakorlatban a legtöbb elemhez 3-5 utility osztály bőven elég. Ettől még lehet egyedi CSS-t írni, amikor a helyzet tényleg megkívánja.
Marcell: Van még valami más előnye is?
Gábor: Igen, mégpedig az, hogy rendkívül AI-kompatibilis. Mivel a HTML és a stílus ugyanabban a fájlban lakik, a mesterséges intelligenciának sokkal kisebb kontextust kell átlátnia, nem kell külön CSS fájlokat keresgélnie és összekötnie. Ez egy óriási plusz pont, ami az utóbbi években vált igazán fontossá.
Marcell: Nehéz volt átállni rá és megszokni?
Gábor: Az elején igen, mert meg kell tanulni a konkrét osztályneveket – szerintem emiatt is utálták olyan sokan a legelején. Most viszont már ott tartok, hogy fejből nyomom a Tailwind kódokat, és néha inkább azt kell ellenőriznem, hogy az adott elnevezés a háttérben milyen hagyományos CSS tulajdonságnak felel meg.
Marcell: Úgy tudom, a Tailwindet külön buildelni (fordítani) kell. Ez nem lassítja a folyamatot?
Gábor: Van hozzá egy build folyamat, de ez a mi érdekünket szolgálja. Mivel a Tailwind rengeteg kész osztályt tartalmaz, a fordító végignézi a projektet, és csak azokat teszi bele a végleges CSS fájlba, amiket valóban használtál. Így a kész alkalmazás mérete sokkal kisebb és gyorsabb lesz.
Marcell: Köszönöm a beszélgetést!
Gábor: Én is köszönöm!
Deutsch
