Kdy nativní CSS, kdy Tailwind, kdy SCSS
Máme na stole tři cesty ke stejnému cíli a otázka „co je nejlepší“ nemá odpověď. Odpověď má otázka „co je nejlepší tady“.
Všechny tři končí obyčejným CSS v prohlížeči. Liší se tím, kde se během psaní rozhoduje o vzhledu a kolik nástrojů k tomu potřebujeme.
| Situace | Volba |
|---|---|
| Malá stránka bez sestavování | nativní CSS |
| Projekt postavený z komponent | Tailwind |
| Projekt, který už SCSS má | SCSS |
| Vlastní design systém s pojmenovanými třídami | SCSS nebo nativní CSS |
| Rychlý prototyp, u kterého jde hlavně o čas | Tailwind |
| Něco, co má bez údržby fungovat i za deset let | nativní CSS |
Co se za posledních pár let změnilo
SCSS vzniklo proto, že CSS neumělo proměnné, zanořování ani rozdělení na
soubory. Dneska umí všechno z toho, takže dřívější samozřejmá volba už
samozřejmá není. Zbývají čtyři věci, kvůli kterým se se SCSS pořád potkáváme:
skládání jmen přes &, mixiny s parametry, cykly a větvení při překladu.
Tailwind naopak nepřidává schopnosti, ale jiný způsob zápisu. Vyplácí se tam, kde se vzhled opakuje v komponentách a kde na projektu dělá víc lidí.
Míchat se to smí
V praxi jsou tyhle tři cesty spíš vrstvy než tábory. Tailwind si drží motiv
v tokenech, tedy ve vlastních vlastnostech. SCSS projekt používá -- proměnné
na to, co se má přepínat za běhu, a $ na to, co se rozhodne při překladu.
Kdo tvrdí, že se musí vybrat jedno a zbytek zavrhnout, většinou prodává kurz.
S vlastní volbou se ostatně tak často nepotkáte. Do projektu se většinou přichází ve chvíli, kdy je cesta dávno zvolená, a úkolem je přizpůsobit se jí. Rozhodovat se budete jednou za čas u něčeho nového – a tehdy je dobré umět volbu obhájit před ostatními.