SASS

Kurz: Eine CSS-Präprozessorsprache — erweitert CSS um Variablen, Verschachtelung und Funktionen, wird vor dem Ausliefern zu normalem CSS kompiliert.

Genauer: Reines CSS hatte lange keine Variablen oder Verschachtelung — SASS (bzw. seine Schreibweise SCSS) füllte diese Lücke, indem man in einer erweiterten Syntax schreibt, die dann zu Standard-CSS kompiliert wird. Seit CSS selbst native Variablen und teils Verschachtelung unterstützt, ist der Vorteil von SASS kleiner geworden, aber in vielen bestehenden Projekten noch fest verankert.

Im Detail

$primaerfarbe: #1a1a1a;
 
.card {
  background: $primaerfarbe;
  .titel {
    font-weight: bold; // verschachtelt statt .card .titel { ... }
  }
}

SASS existiert in zwei Syntax-Varianten: die ursprüngliche, einrückungsbasierte “SASS”-Syntax (ohne geschweifte Klammern/Semikolons) und die heute deutlich gebräuchlichere “SCSS”-Syntax, die wie normales CSS aussieht, nur mit Zusatzfeatures — beide kompilieren zum selben Standard-CSS. Über Variablen und Verschachtelung hinaus bietet SASS Funktionen, Mixins (wiederverwendbare Blöcke von CSS-Regeln mit Parametern) und Vererbung zwischen Selektoren, die native CSS bis heute nicht in vollem Umfang bietet.

Weil moderne CSS-Engines mittlerweile eigene Variablen (--custom-property) und teilweise native Verschachtelung unterstützen, ist ein Teil von SASS’ ursprünglichem Nutzen in den Sprachstandard selbst gewandert — neue Projekte greifen deshalb seltener zu SASS als noch vor einigen Jahren, während viele ältere, große Codebasen weiterhin darauf aufbauen und ein Umstieg selten den Aufwand lohnt.

Mixins und Funktionen

Ein Feature, das native CSS bis heute nicht vollständig nachbildet, sind Mixins — wiederverwendbare Blöcke von CSS-Deklarationen, die mit Parametern aufgerufen werden können, ähnlich einer Funktion in einer Programmiersprache:

@mixin flex-center($richtung: row) {
  display: flex;
  align-items: center;
  justify-content: center;
  flex-direction: $richtung;
}
 
.header { @include flex-center(row); }
.sidebar { @include flex-center(column); }

Das reduziert Wiederholung deutlich, wenn dieselbe Kombination von CSS-Eigenschaften an vielen Stellen mit leichten Variationen gebraucht wird — ein Muster, das native CSS erst mit Container-Queries und @property teilweise nachrüstet, aber nicht mit derselben Flexibilität wie SASS-Mixins.

Kompilierungsschritt als Build-Abhängigkeit

Der zentrale Kompromiss von SASS: Da Browser nur Standard-CSS verstehen, kein SCSS, braucht jedes SASS-Projekt einen Kompilierungsschritt (sass input.scss output.css) als Teil des Build-Prozesses — eine zusätzliche Abhängigkeit und ein zusätzlicher Schritt gegenüber reinem CSS, das der Browser direkt verarbeiten kann. In modernen Frontend-Toolchains (Vite, Webpack, Next.js) ist dieser Schritt meist unsichtbar in den bestehenden Build-Prozess integriert, was den praktischen Mehraufwand für Entwickler gering hält.

Verhältnis zu Utility-First-Frameworks

In den letzten Jahren hat sich mit Utility-First-CSS-Frameworks wie Tailwind CSS ein alternativer Ansatz etabliert, der SASS’ Grundidee (Wiederverwendbarkeit, weniger Wiederholung) anders löst — statt eigene CSS-Klassen mit SASS-Features zu schreiben, kombiniert man viele kleine, vordefinierte Utility-Klassen direkt im HTML/JSX. Beide Ansätze haben aktive Communities; die Wahl hängt oft von Teampräferenz und bestehender Codebasis ab, nicht von einer objektiv “besseren” Lösung.

Siehe auch: CSS, Bootstrap