PostCSS ist noch kein echter Ersatz

Im Zuge des Kittn Updates das derzeit noch läuft, spiele ich einige Szenarien durch die ich dann als Option in den Generator integriere. So auch einen PostCSS only Zweig, das heißt ohne Hilfe von Sass. Ben Frain hat es im Februar 2015 ja auch geschafft (https://benfrain.com/breaking-up-with-sass-postcss/). Mich reizt das Thema ja auch, da ich sich mir auch die Frage stellt wie Zukunftsfähig ist Sass überhaupt noch, ich verwende es jetzt schon seit über sieben Jahren.

PostCSS und Sass kombiniere ich ja schon länger, da war ein optionaler PostCSS Only Zweig kein großer Kulturschock. Und die ersten Schritte waren auch ziemlich angenehm. CSSNext konnte ich zum ersten mal im vollen Umfang nutzen (was in Kombination mit Sass nicht vollständig funktioniert), der Ausflug in die CSS Level 4 Welt war damit gesichert. PostCSS mit CSSNext mutiert ein bisschen zum Babel der CSS Welt, da ich die native Schreibweise vorziehe war ich natürlich begeistert (auch wenn native CSS Variablen immer noch hässlich aussehen, das ist der CSS Validität geschuldet).

Dazu kommen dann weitere Plugins mit denen man Yaml oder JSON Files als Map Files verwenden kann, womit man die Brücke zu Javascript bildet. Auch super. Auch schön, das Plugin mit dem ich per Wildcard alle Files aus einem Verzeichnis lade funktioniert auch, was eine enorme Hilfe für Atomic oder ITCSS darstellt. Soweit so gut dachte ich, jetzt habe weitreichende Konfigurationsmöglichkeiten (externe Maps und interne Variablen) also soll nach dem Einbinden der normalize.css ein Base Style etabliert werden.

Da braucht man Conditions, Extenden will man vielleicht auch, Loops wären vielleicht nicht so verkehrt und private Variablen die man nur innerhalb des Compilers verwendet wären auch nicht verkehrt. Vielleicht will man auch CSS Variablen für einfache Booleans verwenden, was aber mit CSS Variables Plugins A nicht geht, dafür vielleicht mit Plugin B, nur das beißt sich mit einem anderen Plugin. Diese „Sass Like“ Plugins wirken wie ein Fremdkörper in der PostCSS Spähre und so hat man seine liebe Not, das so harmonisch wie möglich aufzustellen. Ich glaube ich hab fast einen ganzen Tag damit verbracht die Reihenfolge der PostCSS so einzustellen, das alles sauber durchläuft.

Der Grundgedanke nur PostCSS zu verwenden ist im Kern ganz nett, man bleibt nah an der nativen Syntax die CSS in Level 4 oder 5 bringt. Das ist wohl der Grundgedanke der Entwickler. Hauptargument ist das man irgendwann PostCSS aus der Pipeline eines bestehenden Projekts ziehen kann, ohne dass man den Source Code anfassen muss. In etwa der gleiche wie bei Babel. Nur unter der Hand, bei Projekten die man nicht mehr weiter pflegt, wird das eh nie passieren, und bei Projekten die man weiter betreut wird PostCSS nicht in Rente geschickt werden, weil man die nächsten upcoming CSS Features heute schon nutzen will (solang man sie emulieren kann)

Insofern ist die Einstellung idealistisch, vor dem Compiler so nativ wie möglich zu arbeiten, aber sie behindert eben auch. Ich kann mir schon vorstellen, das es möglich ist mit PostCSS only zu arbeiten (ohne Sassy Plugins), aber ich denke der Preis ist eben ein höherer Zeitaufwand. Was man mit Sass mit einem Mixin, ein paar Conditions und Loops „abgefrühstückt“, artet in PostCSS eben zum Copy&Pasten und Anpassen aus. Nicht umsonst denkt man heute sogar daran mit Javascript CSS zu schreiben.

Was mir an PostCSS gut gefällt, ist der direkte Zugriff auf den Compiler. Ein bisschen JS und schon hat man eine eigene Funktion geschaffen.

if (decl.value.match(/s/)) {
	const SPACER = parseInt(kc.css.spacer, 10)
	decl.value = SPACER * parseFloat(decl.value) + 'px'
}

In den Task gehängt und schon wird aus einem height: 2s ein height: 40px. In LibSass oder RubySass wird man ähnliches mit @mixins oder @functions regeln, dann ist es halt weniger nativ.

Mein Fazit ist daher gemischt. Der Grundgedanke von PostCSS ist cool, man schreibt so nativ wie möglich, man hat direkten Zugriff zur API die man erweitern kann, aber man versucht sich zu sehr an natives CSS anzulehnen. CSS alleine hat es schwer in der heutigen Zeit, daran werden CSS Vars und Custom Properties nichts ändern. Sass hat man ja auch nicht alleine wegen Vars, Mixins und Nesting genutzt. Die allgemeine Haltung der PostCSS Sphäre ist halt mehr gegen solchen „Spielkram“ und so fühlen sich Conditions wie Fremdkörper an und harmonieren auch nicht sauber mit den anderen PostCSS Plugins. Das finde ich Schade weil es den Compiler in seinen Möglichkeiten limitiert. Ich persönlich fahre daher am besten in dem ich PostCSS und Sass weiterhin kombiniere, ich muss zwar auf ein paar PostCSS Features verzichten, bin dafür bei den logischen Funktionen nicht so stark eingeschränkt.

In Kittn (https://github.com/gisu/generator-kittn) ist die Tür für PostCSS aber weiterhin offen, wer will kann sich dort mit PostCSS Only (mit Sass ähnlichen Features) austoben und die Limits kennen lernen. Wer weiß vielleicht kann man sich damit sogar anfreunden, soll ja auch Entwickler geben die auch heute Precompiler für die Pest halten :D