LESS: Pros und Contras der dynamischen Stylesheet-Sprache

Vor kurzem stieß ich beim Googeln auf einen etwas älteren Blogeintrag über LESS. Der Eintrag ist äußerst euphorisch und spiegelt, so scheint es zumindest, die einhellige Meinung vieler weiterer Blogs zu diesem Thema wieder. Er trägt den Titel "Write Better CSS with Less". Interessanter als den Artikel selbst, fand ich allerdings die Diskussion, die sich in den Kommentaren unterhalb des Eintrags abspielte. Da die dynamische Stylesheet-Sprache nun schon seit etwa einem Jahr zu meinen Arbeitsinstrumenten, nahm ich diesen Zufallsfund zum Anlass für mich selbst ein Resümee zu ziehen.

Zunächst einmal möchte ich meine persönlichen Pros und Contras zu LESS aufzählen. Bei meinen Überlegungen dazu habe ich mich außerdem von einzelnen Kommentaren des Artikels inspirieren lassen. Die grundlegende Frage dieser Auflistung sollte sein: Schreibt man mit Less besseres CSS? Außerdem möchte ich Probleme bei der täglichen Arbeit mit LESS herausstellen, die sich aus dem Umstand ergeben, dass LESS keine vom Browser verstandene Sprache ist und demnach vor der Interpretierung in CSS umgewandelt werden muss. Gleichzeitig möchte ich die einzelnen Punkte auf Ihre unbedingte Richtigkeit hinterfragen.

1. Das Kernargument für LESS ist sicherlich der Umstand, dass man weniger Wiederholungen in seinen CSS-Dateien hat und sich Anweisungen leichter zusammenfassen lassen.

2. Der Code kann insgesamt logischer strukturiert werden, da LESS eine verschachtelte Schreibweise zulässt.

3. Der Code ist einfacher zu warten, da Änderungen zentral vorgenommen werden können.

4. Die Zeilenzahl nimmt ab, was dazu führt, dass die Dateien überschaubarer werden.

5. Globale Änderungen können durch die Verwendung von Variablen leichter durchgeführt.

6. Leichte Automatisierbarkeit.

1. Dadurch, dass LESS zunächst kompiliert wird, kann es schwierig werden Anweisungen wieder zu finden.

2. Es wird versucht eine Stylesheet-Sprache in eine Programmiersprache zu verwandeln.

3. Die Möglichkeiten von Mixins lassen bei komplexeren Problemen zu wünschen übrig.

4. Mit LESS erzeugt man mitunter schlechtes CSS ohne es zu merken.

5. Die Kombination von CSS & HTML bietet bereits ausreichend Möglichkeiten Wiederholungen zu vermeiden.

6. Benennung von Variablen meist schwierig.

7. Es ist nicht möglich ein Mixin von einer Klasse zu unterscheiden.

Für mich persönlich ist dies eines der Hauptargumente für die Nutzung von LESS. Dadurch dass ich beispielsweise Variablen global definieren kann, kann ich im Nachhinein bspw. sehr leicht Farben ändern.

@color: #FF0000;

body {
  color: @color;
}

Allerdings muss man zugeben, dass man dies auch vorher schon konnte. Würde ich in einer reinen CSS-Datei die Farbe #FF0000 ändern wollen, so würde ich dies einfach über "Suchen und Ersetzen" machen.

Wirklich mächtig wäre LESS in diesem Zusammenhang wohl nur, wenn man nur einen Teil der Vorkommen ändern wollen würde und konsequent mehrere Variablen mit gleichem Inhalt verwendet hätte. Das Problem hierbei ist nur: Will man wirklich Dopplungen und wenn ja, was ist ein gesundes Maß?

@color-text: #FF0000;
@color-border: #FF0000;
@color-background: #FF0000;

body {
  color: @color-text;
}

#content {
  border: 1px solid @color-border;
}

#background {
  background: @color-background;
}

Ein weiteres Problem bei der Wartung bzw. Fehlerkorrektur ist die Kompilierung bevor die Datei in den Browser geladen werden kann. Nehmen wir beispielsweise einmal eine verschachtelte Anweisung:

.content {
  margin: 0 auto;
  a {
   color: @color-text; 
   span {
     display: block;
   }
 }
}

Daraus macht der Kompiler Eurer Wahl folgendes CSS:

.content {
  margin: 0 auto;
}
.content a {
  color: @color-text;
}
.content a span {
  display: block;
}

Dadurch dass in der kompilierten CSS-Datei weder Zeilenangaben noch Namensgebung übereinstimmen, wird man sich ein ums andere mal dabei erwischen, wie die Welt im Allgemeinen und LESS im Besonderen verflucht. Abhilfe schafft hier nur sauberes kommentieren, saubere Benennung der Klassen, die auf eine Verschachtelung schließen lässt und natürlich auch der Dateien, wenn der Code in andere Dateien ausgelagert wurde.

Besonders ärgerlich wird die Sache übrigens, wenn Mixins verwendet werden, die aufgrund schlechter Namensgebung und/oder Codestruktur nicht sofort verortet werden können. Auch hier hilft nur sauberes Arbeiten und ein bisschen Glück. Geht immer davon aus, dass Ihr Euch in einem Jahr an nichts mehr erinnern könnt und macht Euch selbst die Sache dann so einfach wie möglich.

Ein weiteres Problem ist die Namensgebung von Variablen. Dadurch dass in Designs beispielsweise eine begrenzte Anzahl von Farben x für eine weit größere Menge an Elementen y verwendet wird, gerät man schnell in Benennungsprobleme. Wie nennt man zum Beispiel eine Farbe, die für die Überschrift, einen Hintergrund der Seitenleiste und als Rahmenfarbe eines Bildes verwendet wird? Nach der hauptsächlichen Nutzung? Dann wäre sie aber bei den anderen Elementen falsch benannt und würde dort verwirren. Schlimmer noch, der Name würde eine einfache Nutzung suggerieren, obwohl sie mehrfach genutzt wird. Ein Workaround wäre wie gesagt die unschöne Dopplung von Variablen, obwohl sie im Grunde genommen das gleiche bedeuten. Ich persönlich habe hier in Ermangelung einer guten Lösung resigniert und nummeriere Farben, Schriften und ähnliches nur noch durch. Suchen muss ich letztendlich sowieso und wenigstens leitet mich der Name dann nicht in die Irre.

LESS ist also nicht wirklich von Haus aus einfacher zu warten. Es erfordert gut durchdachte Code-Strukturen, schlaue Namensgebung und Weitblick.

Das ist meiner Meinung nach eine der unangenehmsten Sachen bei LESS. Durch die Verwendung von Mixins und der daraus resultierenden Schlankheit des Codes wird man schnell eingelullt. Das führt dazu, dass die kompilierte CSS-Syntax klobig und unperformant wird.

Nehmen wir zum Beispiel einmal folgendes Beispiel:

<div class="box box-red-border"></div>
<div class="box box-blue-border"></div>
<div class="box box-green-border"></div>

Mit einem Mixin kann man das super zusammenfassen:

.box(@color) {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid @color;
}
.box-red-border {
  .box(red);
}
.box-blue-border {
  .box(blue);
}
.box-green-border {
  .box(green);
}

Schön übersichtlich oder? Leider sieht das resultierende CSS so aus:

.box {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid ;
}
.box-red-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid red
}
.box-blue-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid blue;
}
.box-green-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid green;
}

Würg, nicht wahr? Reines CSS wäre da um einiges eleganter gewesen.

.box {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid red;
}
.box.box-blue-border {
  border-color: blue;
}
.box.box-green-border {
  border-color: green;
}

Die scheinbare Schlankheit von LESS verleitet schnell dazu Code zu produzieren, der im Endresult extrem hässlich ist. Diesen Umstand sollte man im Kopf behalten, während man programmiert. Achtet also nicht nur darauf, wie schön einfach Euer LESS-Code ist, sondern denkt auch drüber nach, was dann letztendlich dabei herauskommt. Mit LESS erzeugt man nicht automatisch besseres CSS und insofern ist auch die vielzitierte Aussage "LESS ist das bessere CSS" hinfällig. LESS ist nur eine Umschreibung von CSS, behandelt die Sprache entsprechend.

Ein Problem, dass ich relativ häufig gelesen habe, scheint zu sein, dass es keinen erkennbaren Unterschied zwischen Mixins und Klassen gibt. Beide kann man, solange man Mixins ohne Parameter verwendet, syntaktisch nicht unterscheiden. Teilweise wird hier dann eine andere Syntax verlangt.

Tatsächlich halte ich das für Unsinn. Zunächst einmal sollte man sich fragen: Muss ich die beiden unterscheiden können? Ich kann ein Mixin durchaus auch weiterhin als Klasse verwenden. Zudem kann man sich auch schlicht und einfach auf eine Namenskonvention einigen (z.B. .mixin-*) oder man lagert alle Mixins in eine separate Datei aus, was wahrscheinlich am elegantesten wäre.

Eine der angenehmsten Seiten von LESS ist sicherlich die leichte Automatisierung. Lasst mich das anhand eines Beispiels verdeutlichen. Nehmen wir an, dass wir ein Grid-System entwickeln wollen, bei dem wir recht einfach (z.B. wegen eines Responsive Designs) die Breiten der Spalten anpassen können wollen.

@margin : 10px;
@grid_width : 60px;

.mixin-grid(@size : 1) {
  width: @grid_width * @size + 2 * @margin * (@size - 1);
  margin: 0 @margin;
}

.grid {
  position: relative;
  float: left;
}

.grid_1 { .mixin-grid(1); }
.grid_2 { .mixin-grid(2); }
.grid_3 { .mixin-grid(3); }
.grid_4 { .mixin-grid(4); }
.grid_5 { .mixin-grid(5); }
.grid_6 { .mixin-grid(6); }

Und fertig ist unser Grid-System. Will ich nun die Spaltenbreite anpassen, ändere ich einfach nur @grid_width oder @margin und das System passt sich automatisch an. Hier ist LESS unschlagbar und bietet wertvolle Erweiterungen zu CSS, die man zu schätzen lernt.

Wir sind mit der Frage gestartet, ob LESS besseres CSS schreibt. Diese Frage kann ich nur mit einem "Jein" beantworten. Mit LESS schreibt man nicht automatisch besseres CSS, tatsächlich schreibt man sogar (wenn man das System nicht durchblickt) unter Umständen wesentlich schlechteres. Mit LESS kann man einfacheres CSS schreiben, zumindest wenn man sich an gewisse Regeln hält. LESS hat einige mächtige Instrumente, die einem das Leben wirklich erleichtern können, allerdings hat LESS auch seine Schattenseiten. Diese resultieren daraus, dass LESS eben kein besseres CSS ist, sondern nur eine vereinfachte Schreibweise mit einigen zusätzlichen Möglichkeiten.

Ist man sich dieser Probleme bewusst, so kann man sich mit LESS durchaus anfreunden und sich die Arbeit leichter machen. Man kann sogar angenehmes CSS dabei zustande bringen. Handgefertigtes, intelligent verwendetes CSS wird LESS aber niemals ersetzen können. Genauso wenig wie ein Schrank eines schwedischen Möbeldiscounters den handgefertigten Schrank vom Schreinermeister um die Ecke ersetzen kann. Aber der Schrank des Möbeldiscounters ist mitunter die kostengünstigere Variante und letztendlich wird man immer Qualität gegen Effizienz abwägen müssen. Ich werde deswegen weiterhin LESS verwenden, auch wenn ich nach einem Jahr Nutzung mittlerweile etwas ernüchtert bin.