Präprozessor-Pein

Die Älteren unter euch werden sich erinnern, wie schlimm wir alle es immer fanden, CSS zu schreiben. Furchtbar! Eine Qual! – … – Nicht?! Eigentlich mochten es alle, dass CSS so wunderbar direkt und zugänglich ist? Man hat sich höchstens ab und an mal die Möglichkeit von Variablen in CSS gewünscht, dies aber jederzeit sauber und unkompliziert durch gut strukturierte Styles oder halt durch per PHP erzeugte Stylesheets gelöst?

Ja, hmm, stimmt – wenn ich’s recht bedenke, war es genau so. Wir haben alles hinbekommen und auch vor SCSS und Less zum Teil riesige und komplexe Web-Projekte gestemmt. Und diese Projekte machten uns keine Magengeschwüre bei der langfristigen Wartung oder bei Änderungen und Erweiterungen.

Wie haben wir das nur gemacht? Nun: es gab zum einen damals einen Konsens, dass Webdesign nicht Plakatdesign ist. Ein guter Webdesigner hatte das Medium vor Augen und zumindest in Grundsätzen die Logik von HTML-Markup und CSS. Man bemühte sich um ein konsistentes Design, um ein klares typografisches Konzept mit möglichst wenigen verschiedenen Varianten und um eine begrenzte Sammlung von Elementen, die klar durch Inhalt und Funktion definiert waren.

Eben: kein Plakatdesign. Kein Malen einzelner Seiten, in die aus dem Stegreif immer neue Schriftvarianten und Elemente oder Elementmutationen hineingepinselt werden.

Das machte es den Frontendern leicht, die Styles modular und übersichtlich aufzubauen. Das Grundsätzliche zuerst, das Spezielle danach. Erst Typografie und Farben, dann Seitenlayout und Basiselemente, dann die spezielleren Dinge.

Es gab kein Problem. Das war weder teurer als heute, noch waren die Stylesheets schlechter oder schlechter wartbar, noch war das Arbeiten damit qualvoll. Und wie gesagt: die Projekte an sich waren nicht weniger komplex als heute.

Und doch glauben wir heute, dass es ohne SCSS oder Less nicht gehe. Dass es irgendwie unprofessionell oder zumindest erklärungsbedürftig sei, einfach nur reines CSS zu schreiben.

Das ist eine ganz unsinnige Entwicklung. Wir haben etwas Einfaches, Solides, direkt Zugängliches und dabei wunderbar Mächtiges ersetzt durch etwas Kompliziertes, das nicht einmal auf eigenen Beinen steht, sondern vor der Verwendung erst einmal durch den Präprozessor gejagt werden muss. Wir haben einen klaren, gut lesbaren Standard, der seit 20 Jahren fast ohne syntaktische Änderungen gilt, ersetzt durch einen unhandlichen proprietären Dialekt, der vielleicht in zwei Jahren wieder veraltet ist.

Und was dadurch gewonnen?

Der Autor und Entwickler Jens Meiert schreibt ganz richtig: CSS preprocessors are like a solution in need of a problem to me.

Ich will SCSS nicht verteufeln. Es mag bei wirklich komplexen Software-Projekten Vorteile bieten. Vielleicht … – Aber in den meisten Fällen scheint mir auch hier wieder so ein Hang zum Sichaufblasen, zur »Verwissenschaftlichung« von etwas eigentlich Einfachem zum Tragen zu kommen.

Und überdies habe ich den Verdacht, dass einige Probleme, die wiederum mit BEM gelöst werden sollen, überhaupt erst durch den – unbedachten – Einsatz von SCSS/Less entstanden sind.

Vor allem das Problem, den Überblick zu behalten über die Stärke der Selektoren: es lässt sich in SCSS alles so schön sauber schachteln – das sieht so wunderbar sauber aus, dass man schnell vergessen kann, was »hinten rauskommt«, und der Illusion von echten Blöcken und Namespaces wie in Programmiersprachen erliegt. Und plötzlich steht man dann eben da mit wahnsinnig starken Selektoren – und findet, dass man so etwas wie BEM braucht …