Směřuje CSS od preprocesingu k postprocesingu?

Myslím, že ano. Preprocesory přišly s řadou užitečných vlastností a vyplňují potřeby, které samotné CSS nezvládalo uspokojit. Přišel ale Grunt a Gulp, změnily se naše pracovní postupy a některé důvody pro preprocesory se tím vytratily.

Sám dnes CSS preprocesory používám prakticky pro všechny projekty. Souběžně s neutuchajícím nadšením pro LESS a jeho partu u mě ovšem probíhá postupný ústup od všech jejich pokročilých vlastností.

Vyvrcholením trendu bylo zamyšlení zda preprocesory vůbec potřebuji. Tenhle skvělý článek od Cole Peterse mě pak přinutil sepsat nynější stav mysli.

Potřebuji preprocesory? Zatím ano, hlavně kvůli proměnným

Vezměme to po jednotlivých základních vlastnostech:

@import a slučování do jednoho souboru

Skvělá věc, protože krátí dobu načítání stánek. Umíme ale vyřešit i bez preprocesorů. Nějakým css-concat podobně jako u Javascriptů.

Mixiny pro CSS3 vlastnosti

Prefixované vlastnosti nám jednu dobu docela zatápěly, že jo? Dneska už to takový problém není. Navíc máme Autoprefixer. Postprocessing jako vyšitý.

Zanořování deklarací

„Dobrý sluha, ale zlý pán” tady platí úplně nejvíc. Pro nezkušené kodéry by bylo lepší kdyby tahle vlastnost nikdy nevznikla. A s metodikou OOCSS to preprocesorové zanořování zas tak nepotřebují ani ti zkušení.

Matematika

V LESSu jsem si dost oblíbil třeba percentage(2/3). Bez preprocesorové matematiky bych ale přežít dokázal. Nativní funkce calc() má hezkou podporu.

Cykly, podmínky, extend a další vlastnosti

Počkejte, vy je vážně používáte? :-) Ale jo, uznávám, že nastavení týmu a projektu může být takové, že jsou pro vás nepostradatelné. Chápu, pokud děláte CSS animace nebo grid systémy. Tvrdím ale, že pro většinu užití preprocesorů jde o zbytný syntaktický cukr.

Proměnné

Tady se nechávám podat. Těžko je něčím nahradíte. Aktuálně používám preprocesory hlavně kvůli nim. Ale blýská se na lepší časy, ještě chvíli čtěte.

Nevýhody CSS preprocesorů

1. Až moc silný nástroj – odklon od tuposti CSS a příliš mnoho abstrakce sice vede k propracovanému, někdy až imperativnímu kódu. Zároveň často ale špatně čitelnému a spravovatelnému.
2. Proprietární kód – pokud preprocesory využíváte „tupě“, je zaučení nového člověka nebo přechod na jiný preprocesor relativně jednoduché; horší je to ovšem v kombinaci v prvním bodem.

Postprocessing s cssnext

Všimněte si, že téměř všechny uvedené základní vlastnosti preprocesorů — s čestnou výjimkou proměnných — dnes umíme nahradit s pomocí Gruntu.

Hlavní výhoda následného zpracování je v tom, že CSS píšeme v dnešní syntaxi. Případně v syntaxi standardizované, ale prohlížeči zatím neimplementované.

Podívejte se hlavně na projekt cssnext. Ano, W3C.org připravuje standard pro CSS proměnné, matematiku, vlastní media queries a další. A díky CSSnext je budete moci vužívat už dneska. Třeba proměnné:

.box {
  --text-color: black;
  color: var(--text-color);
}

Vracíme se tedy k deklarativní a (v dobrém smyslu) tupé povaze jazyka. Vyhýbáme se přílišné abstrakci preprocesorů. Náš kód bude snáze naučitelný a přenosný, protože jsme se zbavili jeho proprietární, nepřenosné syntaxe. A s vysokou pravděpodobností je dopředně kompatibilní.

Postprocessing přitom to není nic nového. Sám pomocí Gruntu do CSS už pěkných pár měsíců přidávám pixelový fallback pro rem jednotku, prefixované verze vlastností nebo generuji CSS pro prohlížeče co neumí Media Queries.

Pro postprocessing mluví i možnost výběru sady vlastností. Sami můžete říct zda CSSko obohatíte jen o proměnné nebo i něco dalšího. A kromě jiného si tím také brutálně zrychlit kompilaci.

Tohle všechno ještě před pár lety nebylo možné. Nebyl Grunt, Gulp a nekonečné množství jejich pluginů. CSS se pod taktovkou W3C skoro nevyvíjelo. Postupy jako OOCSS nebo BEM používala jen hrstka zasvěcených. Do tehdejšího světa preprocesory zapadaly zcela dokonale.

Pojďme to vyzkoušet

Na papíře vypadá postprocessing skvěle. Musí se ale ověřit praxí. Nevím jak vy, ale já to jdu zkusit hned na příštím projektu.