Sass vs. Less

„Welche CSS-Präprozessor-Sprache sollte ich wählen?“ ist in letzter Zeit ein heiß diskutiertes Thema. Ich wurde mehrmals persönlich danach gefragt, und eine Online-Debatte scheint alle paar Tage aufzutauchen. Es ist gut, dass sich die Diskussion größtenteils von der Frage, ob Präprozessierung eine gute Idee ist oder nicht, zu der Frage verschoben hat, welche Sprache die beste ist. Lasst uns das angehen.

Wirklich kurze Antwort: Sass

Etwas längere Antwort: Sass ist in vielerlei Hinsicht besser, aber wenn du mit Less glücklich bist, ist das in Ordnung, zumindest tust du dir selbst einen Gefallen, indem du präprozessierst.

Viel längere Antwort: Lies weiter.

Die viel längere Antwort

Die Lernkurve mit Ruby und Kommandozeile und was auch immer

Die einzige Lernkurve ist die Syntax. Sie sollten eine App wie CodeKit, LiveReload oder Mixture verwenden, um Ihre erstellten Dateien zu überwachen und zu kompilieren. Sie müssen keine Ahnung von Ruby oder der Kommandozeile oder was auch immer haben. Vielleicht sollten Sie das, aber Sie müssen es nicht, also ist es hier kein Faktor. Die Tatsache, dass Sass in Ruby und Less in JavaScript ist, ist für die meisten potenziellen Benutzer von geringer Bedeutung.

Gewinner: Niemand

Hilfe mit CSS3

Mit beiden Sprachen können Sie Ihre eigenen Mixins schreiben, um mit Vendor-Präfixen zu helfen. Kein Gewinner dort. Aber wissen Sie, wie Sie nicht zurückgehen und die Präfixe aktualisieren, die Sie in all Ihren Projekten verwenden? (Das tun Sie nicht.) Sie werden auch Ihre handgefertigte Mixin-Datei nicht aktualisieren. (Wahrscheinlich.)

In Sass können Sie Compass verwenden, und Compass **wird** sich selbst auf dem neuesten Stand halten, und somit ist die Präfix-Situation für Sie erledigt. Bourbon ist auch gut. Es wird einige Hin und Her geben, welches dieser Projekte "vor" ist.

In Less gibt es auch einige Mixin-Bibliotheken, die um die beste kämpfen. Sie sehen heute viel besser aus als früher. Trotz ihrer Marketing-Support-Charts glaube ich nicht, dass sie so robust sind wie die Sass-Versionen. Ich habe mir sagen lassen, dass die Sprache Less selbst es nicht zulässt, robustere Bibliotheken darauf aufzubauen. Dazu kommen wir gleich.

In beiden Fällen liegt es an Ihnen, die Präprozessor-Software selbst sowie diese Bibliotheken auf dem neuesten Stand zu halten. Ich finde es generell auch bei Sass einfacher. Zum Beispiel werden Compass-Updates automatisch in CodeKit kommen, oder Sie verwenden ein Gem, das einfach zu aktualisieren ist, während Sie bei Less-Mixins eine Datei selbst manuell aktualisieren müssen.

Gewinner: Knapp Sass

Sprachfähigkeiten: Logik / Schleifen

Less hat die Fähigkeit, „guarded mixins“ zu verwenden. Dies sind Mixins, die nur dann wirksam werden, **wenn** eine bestimmte Bedingung wahr ist. Vielleicht möchten Sie eine Hintergrundfarbe basierend auf der aktuellen Textfarbe in einem Modul festlegen. Wenn die Textfarbe „ziemlich hell“ ist, möchten Sie wahrscheinlich einen dunklen Hintergrund. Wenn sie „ziemlich dunkel“ ist, möchten Sie einen hellen Hintergrund. Sie haben also ein einzelnes Mixin, das in zwei Teile aufgeteilt ist, mit diesen Guards, die sicherstellen, dass nur einer davon wirksam wird.

.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) { 
  background: black;
}
.set-bg-color (@text-color) when (lightness(@text-color) < 50%) { 
  background: #ccc;
}

Dann erhalten Sie bei der Verwendung den richtigen Hintergrund

.box-1 {
  color: #BADA55;
  .set-bg-color(#BADA55);
}

Das ist stark vereinfacht, aber Sie verstehen wahrscheinlich, worum es geht. Sie können damit einige ausgefallene Dinge tun. Less kann auch selbstreferenzierende Rekursion betreiben, bei der ein Mixin sich selbst mit einem aktualisierten Wert aufrufen kann, wodurch eine Schleife entsteht.

.loop (@index) when (@index > 0) {
  .myclass {
    z-index: @index;
  }
  // Call itself
  .loopingClass(@index - 1);
}
// Stop loop
.loopingClass (0) {}

// Outputs stuff
.loopingClass (10);

Aber dort enden die Logik-/Schleifenfunktionen von Less. Sass hat tatsächliche Logik- und Schleifenoperatoren in der Sprache. Wenn/dann/sonst-Anweisungen, For-Schleifen, While-Schleifen und Each-Schleifen. Keine Tricks, nur richtige Programmierung. Während guarded mixins ein ziemlich cooles, natürliches Konzept sind, geht die Sprachrobustheit an Sass. Diese Sprachrobustheit ist es, die Compass ermöglicht.

Zum Beispiel hat Compass ein Mixin namens background. Es ist so robust, dass Sie ihm fast alles übergeben können, was es ausgeben soll. Bilder, Verläufe und jede Kombination davon, durch Kommas getrennt, und Sie erhalten, was Sie brauchen (inklusive Vendor-Präfixe).

Dieser prägnante und verständliche Code

.bam {
  @include background(
    image-url("foo.png"),
    linear-gradient(top left, #333, #0c0),
    radial-gradient(#c00, #fff 100px)
  );
}

Wird zu diesem Monster (was leider das ist, was wir brauchen, damit es mit der bestmöglichen Browserunterstützung funktioniert)

.bam {
  background: url('/foo.png'), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff));
  background: url('/foo.png'), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px);
}

Gewinner: Sass

Webseiten-Nettigkeit

Less hat eine nettere, gebrauchsfähigere Website. Die Sass-Dokumentation ist nicht schlecht. Sie ist vollständig und man findet, was man braucht. Aber wenn es darum geht, die Aufmerksamkeit von Frontend-Leuten zu gewinnen, hat Less die Nase vorn. Ich zweifle nicht daran, dass dies eine große Rolle dabei spielt, dass Less derzeit das Rennen um die Popularität anführt.

Ich weiß, dass die Sass-Website eine große Überarbeitung durchläuft und viele großartige Leute daran arbeiten. Es scheint mir jedoch, dass es sehr langsam vorangeht.

Gewinner: LESS

Das @extend-Konzept

Angenommen, Sie deklarieren eine Klasse mit etwas Styling. Dann möchten Sie eine weitere Klasse, die fast das Gleiche tun soll, nur ein paar zusätzliche Dinge. In Less würden Sie wahrscheinlich

.module-b {
   .module-a(); /* Copies everything from .module-a down here */
   border: 1px solid red;
}

Das ist im Wesentlichen ein „Include“. Ein Mixin, in beiden Sprachen. Sie könnten ein Include verwenden, um das auch in Sass zu tun, aber Sie sind besser dran, @extend zu verwenden. Mit @extend werden die Stile von .module-a nicht nur nach .mobule-b (was als Ballast betrachtet werden könnte) dupliziert, sondern der Selektor für .module-a wird in den kompilierten CSS zu .module-a, .module-b geändert (was effizienter ist).

.module-a {
   /* A bunch of stuff */
}
.module-b {
   /* Some unique styling */
   @extend .module-a;
}

Kompiliert zu

.module-a, .module-b {
  /* A bunch of stuff */
}
.module-b {
  /* Some unique styling */
}

Sehen Sie das? Es schreibt Selektoren neu, was viel effizienter ist.

In Less ist jede einzelne Klasse auch ein Mixin, was die Angelegenheiten programmatisch etwas unübersichtlich macht, aber auf den ersten Blick einfacher zu verstehen ist.

Ab Less 1.4 unterstützt es auch extend. Sie können einige Beispiele sehen wenn wir darauf aktualisieren auf CodePen. Es ist ein bisschen schrullig, da es keine Selektoren erweitert, die in der ursprünglichen Klasse verschachtelt sind, es sei denn, Sie verwenden ein zusätzliches all-Schlüsselwort. Die Option, entweder den einen oder den anderen Weg zu gehen, erscheint mir tatsächlich mächtiger, aber ich bin auch vorsichtig bei dem, was unter der Haube vor sich geht.

Sass hat auch die Fähigkeit, „Platzhalter“-Klassen zu erweitern. Im Wesentlichen unsichtbare Klassen im Format %placeholder { }. Dies ist nützlich, um interne Benennungen zu verwenden, die dort sinnvoll sind, aber keine tatsächlichen Klassennamen wären.

Gewinner: Sass

Variablenbehandlung

Less verwendet @, Sass verwendet $. Das Dollarzeichen hat keine inhärente Bedeutung in CSS, während das @-Zeichen dies hat. Es ist für Dinge wie die Deklaration von @keyframes oder Blöcken von @media-Abfragen. Man könnte dies der persönlichen Vorliebe zuordnen und es als keine große Sache betrachten, aber ich denke, der Vorteil liegt bei Sass, das keine stehenden Konzepte verwirrt.

Sass hat jedoch einige Merkwürdigkeiten mit dem Gültigkeitsbereich von Variablen. Wenn Sie eine „globale“ Variable „lokal“ überschreiben, übernimmt die globale Variable den lokalen Wert. Das fühlt sich einfach etwas komisch an.

$color: black;           
.scoped { 
  $color: white;
  color: $color;        
}                        
.unscoped {     
  // LESS = black (global)
  // Sass = white (overwritten by local)
  color: $color;          
}

Ich habe gehört, dass es nützlich sein kann, aber es ist nicht intuitiv, besonders wenn man JavaScript schreibt.

Gewinner: Unentschieden

Arbeiten mit Media Queries

Die Art und Weise, wie die meisten von uns mit @media-Abfragen zu arbeiten begannen, war, Blöcke davon am Ende ihres Haupt-Stylesheets hinzuzufügen. Das funktioniert, führt aber zu einer mentalen Trennung zwischen den ursprünglichen Stilen und den reaktionsfähigen Stilen. Wie

.some-class {
   /* Default styling */
}

/* Hundreds of lines of CSS */

@media (max-width: 800px) {
  .some-class {
    /* Responsive styles */
  }
}

Mit Sass oder Less können wir diese Stile durch Verschachtelung zusammenbringen.

.some-class {
  /* Default styling */
  @media (max-width: 800px) {
    /* Responsive styles */
  }
}

Mit Sass können Sie es sogar noch besser machen. Es gibt eine wirklich coole „respond-to“-Technik (siehe Code von Chris Eppstein, Ben Schwarz und Jeff Croft) zum Benennen/Verwenden von Breakpoints.

=respond-to($name)

  @if $name == small-screen
    @media only screen and (min-width: 320px)
      @content

  @if $name == large-screen
    @media only screen and (min-width: 800px)
      @content

Dann können Sie sie prägnant und semantisch verwenden

.column
    width: 25%
    +respond-to(small-screen)
      width: 100%

Verschachtelte Media Queries sind eine fantastische Arbeitsweise. Gerüchten zufolge wird Sass 3.3 weitere Funktionen enthalten, um dies noch nützlicher zu machen, einschließlich einer Möglichkeit, extend innerhalb von Media Queries zu verwenden, was derzeit sowohl in Less als auch in Sass unmöglich ist.

Gewinner: Sass

Mathematik

Zum größten Teil ist die Mathematik ähnlich, aber es gibt einige Merkwürdigkeiten bei der Handhabung von Einheiten. Zum Beispiel nimmt Less an, dass die erste verwendete Einheit das ist, was Sie ausgeben möchten, und ignoriert weitere Einheiten.

div {
   width: 100px + 2em; // == 102px (weird)
}

In Sass erhalten Sie einen klaren Fehler: Inkompatible Einheiten: ‚em‘ und ‚px‘. Ich schätze, es ist umstritten, ob es besser ist, einen Fehler zu bekommen oder falsch zu liegen, aber persönlich ziehe ich den Fehler vor. Insbesondere wenn Sie mit Variablen und nicht mit direkten Einheiten arbeiten und es schwerer zu finden ist.

Sass lässt Sie auch mathematische Operationen mit „unbekannten“ Einheiten durchführen, was es etwas zukunftssicherer macht, falls eine neue Einheit auftaucht, bevor sie sie aktualisieren können. Less tut dies nicht. Es gibt noch einige weitere seltsame Unterschiede, wie Sass das Multiplizieren von Werten mit Einheiten behandelt, aber das ist esoterisch genug, um es nicht erwähnenswert zu machen.

Gewinner: Knapp Sass

Aktive Entwicklung

Keines dieser Dinge ist ein endgültiger Beweis dafür, dass ein Projekt aktiver ist als das andere, aber es ist interessant, sich die Statistiken anzusehen. Soweit ich weiß, arbeiten die Leads beider Sprachen in ihrer knappen Freizeit daran, da beide andere wichtige neue Projekte haben, an denen sie arbeiten.

Less war in letzter Zeit ziemlich aktiv, aber jetzt ist auch Sass viel aktiver geworden, da sich ein Kernmitglied direkt darauf konzentrieren kann.

Gewinner: Unentschieden

Weitere Lektüre

• Chris Eppstein: Sass/LESS Vergleich
• Jeremy Hixon: Eine Einführung in LESS und ein Vergleich mit Sass
• Ken Collins: Zu LESS? Sollten Sie Sass verwenden?
• Johnathan Croom: Sass vs. LESS vs. Stylus: Ein Präprozessor-Shootout