SASS ist ein CSS-Präprozessor: Man schreibt Stylesheets in einer erweiterten Syntax, die anschließend in normales CSS übersetzt wird. In der SASS-Entwicklung nutzen wir die SCSS-Schreibweise, die wie CSS aussieht und um Variablen, Verschachtelung, Mixins, Funktionen und Module ergänzt ist. Im Browser kommt am Ende ganz gewöhnliches CSS an – nur deutlich besser organisiert entstanden.
Wir setzen SASS auch selbst ein: Unsere eigene Website sphinx-flashdesign.de ist mit Laravel, Blade und SASS gebaut. Für Projekte mit vielen Seiten, mehreren Marken oder einem Team, das gemeinsam an den Styles arbeitet, ist SASS eine bewährte Grundlage.
Mit SCSS legen Sie Farben, Schriften, Abstände und Umbruchpunkte einmal zentral fest und verwenden sie überall. Mixins bündeln wiederkehrende Regeln, etwa für Medienabfragen oder Fokus-Zustände; eigene Funktionen berechnen Werte wie Abstände oder Farbabstufungen. Über das Modulsystem mit @use und @forward bleibt nachvollziehbar, welche Datei welche Variablen bereitstellt.
Die ältere @import-Regel gilt in Dart Sass, der heute maßgeblichen Implementierung, als veraltet. Bestehende Projekte stellen wir deshalb schrittweise auf das Modulsystem um, damit sie auch mit künftigen Versionen von SASS fehlerfrei kompilieren.
Ein Design-System sorgt dafür, dass Buttons, Formulare, Karten und Überschriften überall gleich aussehen und sich gleich verhalten. In SASS bilden wir es mit Design-Tokens für Farben, Typografie und Abstände ab und ordnen die Styles in Teildateien nach Komponenten. Neue Seiten setzen sich dann aus vorhandenen Bausteinen zusammen, statt jedes Mal neue Regeln zu erfinden.
SASS-Variablen und CSS Custom Properties ergänzen sich dabei: Erstere strukturieren den Code beim Entwickeln, letztere lassen sich im Browser ändern, etwa für einen Dunkelmodus oder verschiedene Markenfarben. Die gestalterische Seite eines Design-Systems beschreiben wir unter UX- und UI-Design.
Damit aus SCSS fertiges CSS wird, braucht es einen Build-Schritt. Wir richten ihn mit gängigen Werkzeugen wie Vite oder webpack ein, ergänzen bei Bedarf PostCSS mit Autoprefixer und erzeugen für die Entwicklung Source Maps, damit sich jede Regel im Browser auf ihre Quelldatei zurückführen lässt. Für den Livebetrieb wird das CSS minimiert und mit einer Versionskennung versehen, sodass Browser nach einem Update zuverlässig die neue Datei laden.
In Laravel-Projekten binden wir den Build direkt in den gewohnten Ablauf ein, bei WordPress-Themes ebenso.
Ältere Projekte nutzen oft noch Node Sass oder LibSass. Beide werden nicht mehr weiterentwickelt, und neuere SASS-Funktionen stehen dort nicht zur Verfügung. Wir stellen solche Projekte auf Dart Sass um, beheben die Warnungen zu veralteten Funktionen und räumen dabei auf: doppelte Regeln, zu tief verschachtelte Selektoren, ungenutzte Teildateien.
Nicht jedes Projekt braucht SASS. Für kleinere Websites reicht oft modernes CSS mit Custom Properties und Verschachtelung, das inzwischen alle aktuellen Browser beherrschen. Wir empfehlen, was zu Umfang, Team und Laufzeit Ihres Projekts passt.
Ihr CSS ist über die Jahre gewachsen und schwer zu pflegen? Wir sehen es uns an und schlagen einen gangbaren Weg vor – mit einem kostenlosen Angebot.
Unser Studio liegt in Königstein im Taunus. Wir kommen zu Ihnen oder sprechen per Video-Call – hier finden Sie unsere Seiten für Ihren Ort:
Beides gehört zu SASS. SCSS ist die heute übliche Schreibweise mit geschweiften Klammern und Semikolons wie in CSS; jede gültige CSS-Datei ist auch gültiges SCSS. Die ältere, eingerückte Syntax kommt ohne Klammern aus und ist seltener anzutreffen.
Für kleine Projekte oft nicht. Bei größeren Codebasen bietet SASS aber weiterhin Vorteile: Mixins, Funktionen, Schleifen und ein Modulsystem, das Abhängigkeiten zwischen Dateien klar regelt. Wir entscheiden das je nach Projekt.
Nein. SASS wird vor der Veröffentlichung in normales CSS übersetzt; im Browser kommt also ganz gewöhnliches CSS an. Die Vorteile liegen in der Entwicklung: weniger Fehler, schnellere Änderungen und ein einheitliches Erscheinungsbild.
