Mir gefällt die SASS-Syntax aufgrund ihrer Kürze besser als die SCSS-Syntax. Aber die massive Verschachtelung von Stilen in SASS kann die Vorteile seiner Kürze schnell zunichte machen. Auf jeden Fall ist der Unterschied zwischen SASS und SCSS nicht grundlegend. Es stellte sich heraus, dass LESS näher an SCSS als an SASS lag. Und im Allgemeinen ist es dasselbe. Es gibt nicht viele Unterschiede, aber einige davon verändern die Machtverhältnisse grundlegend.

1. WENIGER – kann clientseitig mit JS erfolgen.

Genauer gesagt ist es nicht so, dass er es kann, er ist dafür geschaffen. Gängige Vorgehensweise bei der Verwendung von LESS-Code:

Zu diesem Zeitpunkt wurde die Möglichkeit hinzugefügt, auf dem Server zu kompilieren (sowohl js als auch Ruby).

Auf den ersten Blick scheint es eine seltsame Immobilie zu sein. Warum auf der Client-Seite kompilieren, wenn man auf dem Server perfekt kompilieren und fertiges komprimiertes CSS bereitstellen kann, wie wir es von SASS gewohnt sind?

Der Grund wird klar, wenn man die unscheinbaren allerletzten Zeilen der LESS-Dokumentation studiert:

@height: `document.body.clientHeight`;

Eine so kleine, einsame Linie bietet Möglichkeiten, von denen Layoutdesigner seit Beginn der Beherrschung von Stilen nur geträumt haben. Aufrufen eines clientseitigen Java-Skripts aus CSS und Berücksichtigung tatsächlicher Browsereinstellungen beim Erstellen von Stilen.

Das heißt, wir haben jetzt die Möglichkeit, zuerst das DOM zu laden und dann direkt auf der Clientseite spezielles CSS dafür zu erstellen. Dann überlegen Sie selbst, welche Chancen sich dadurch eröffnen.

Ob Ihr Projekt dies benötigt, ist eine andere Frage. Es ist klar, dass jeder an die Unsicherheit/Unabhängigkeit des Kunden gewöhnt ist und ein Layout im Stil von „Wir machen es universell, sodass es mehr oder weniger jedem bei allen Auflösungen gezeigt wird“ bietet. Dies ist jedoch kein Grund zu vergessen, dass jetzt eine solche Möglichkeit besteht und Sie damit beispielsweise ein sehr flexibles Layout erstellen können.

2. LESS hat im Gegensatz zu SASS/SCSS keine Logik.

In LESS gibt es kein Wenn/Dann, Für usw. Wenn man jedoch bedenkt, dass JS leicht darin integriert werden kann, denke ich, dass es durchaus möglich ist, die Logik einzubauen. Ich habe es nicht ausprobiert.

3. Das Mischen ist in LESS einfacher + Sie können Klassen mischen.

Besonders gut hat mir gefallen, dass man in LESS Eigenschaften anderer Klassen in die Definition einbeziehen kann. Die Klasse selbst ist ein Mixin. Dies ist eine weitere Funktion, die SASS/SCSS nicht bietet. Sie können eine reguläre CSS-Datei in LESS einbinden und deren Klassen zum Definieren Ihrer Eigenschaften verwenden. Zum Beispiel:

Wickeln (
Textumbruch: umbrechen;
Leerraum: vor dem Umbruch;
Leerraum: -moz-pre-wrap;
Zeilenumbruch: Wortumbruch;
}
pre ( .wrap )

Zusammenfassung

Mit Ausnahme des 1. Punktes ist der Unterschied nicht groß und die Auswahl für den Amateur größer.

Für mich persönlich sieht LESS aufgrund seiner Einfachheit attraktiver aus. Ich habe noch nie zuvor Zyklen und Bedingungen in Stilen benötigt. Klassische Dienstprogramme wie „Box-Shadow, Linear-Gradient, Darken“ sind in LESS verfügbar.

Ja, viele vorgefertigte Bibliotheken wurden bereits für SASS geschrieben (

„Und es stellte sich eine völlig logische Frage: „Was ist der Unterschied zwischen SASS und SCSS?“ Das Thema ist interessant, also lasst es uns herausfinden.

Wann wir reden über Wenn wir von Sass sprechen, meinen wir im Allgemeinen den Präprozessor und die Sprache im Allgemeinen.

Mit Sass (Präprozessor) können wir jedoch zwei verschiedene Syntaxen verwenden:

• Sass(Einrückung) ;
• SCSS (CSS-ähnliche Syntax).

Eine kleine Geschichte

Sass war ursprünglich Teil eines anderen Präprozessors, Haml, der von Ruby-Entwicklern erfunden und geschrieben wurde.

Daher verwendeten Sass-Stile eine Ruby-ähnliche Syntax, keine Klammern, keine Semikolons und keine strikte Einrückung, wie folgt:

// Variable!primär -color= hotpink // Primär =border-radius(!radius) -webkit-border-radius= !radius -moz-border-radius= !radius border-radius= !radius .my-element color= !primary -color width= 100 % overflow= versteckt .my-other-element +border-radius(5 px)

Es gibt einen deutlichen Unterschied zur CSS-Syntax.

Die Variable wird über ! angegeben. , nicht $ , Wertzuweisungssymbol = , nicht :.

Aber so sah Sass bis zur Version 3.0 aus, die im Mai 2010 veröffentlicht wurde und eine völlig neue Syntax namens SCSS oder Sassy CSS einführte.

Sein Ziel war es, die Sass-Syntax näher an CSS heranzuführen und sie damit besser mit CSS kompatibel zu machen:

// Variable $primary -color: hotpink; // Mixin @mixin border-radius($radius ) ( -webkit-border-radius: $radius ; -moz-border-radius: $radius ; border-radius: $radius ; ) .my-element ( color: $primary -color; Breite: 100 %; Überlauf: versteckt; ) .my-other-element ( @include border-radius(5 px); )

SCSS ist definitiv näher an CSS als Sass. Die Sass-Entwickler haben hart daran gearbeitet, beide Syntaxen einander anzunähern, indem sie ! (Variablenzeichen) und = (Zuweisungszeichen) auf $ und: aus CSS.

Wenn Sie also ein neues Projekt starten, fragen Sie sich möglicherweise, welche Syntax Sie verwenden sollen. Ich helfe Ihnen bei der Entscheidungsfindung.

Profis Sass-Syntax eingerückt

Obwohl Ihnen diese Syntax vielleicht etwas seltsam erscheint, enthält sie einige interessante Punkte. Erstens ist es kürzer und einfacher zu tippen. Es gibt keine Klammern oder Semikolons, sie werden nicht benötigt.

Es ist weder @mixin noch @include erforderlich, wenn ein einfaches Symbol: = und + ausreicht.

Sass verfügt aufgrund der Verwendung von Einrückungen auch über saubere Codierungsstandards. Da eine falsche Einrückung das gesamte .sass-Stylesheet beschädigen kann, besteht der erste Schritt hier darin, sicherzustellen, dass der Code sauber und richtig formatiert ist.

Es gibt nur eine Möglichkeit, Sass-Code zu schreiben: richtig schreiben.

Vergessen Sie nicht, dass Einrückungen in Sass einen booleschen Wert haben. Wenn eine Selektorblockeinrückung angewendet wird, bedeutet dies, dass es sich um einen verschachtelten Selektor handelt.

Zum Beispiel:

.element-a color: hotpink .element-b float: left ... gibt den folgenden CSS-Code aus: .element-a ( color : hotpink ; ) .element-a .element-b ( float : left ; )

Die einfache Tatsache, dass .element-b um eine Ebene nach rechts verschoben wird, bedeutet, dass dies der Fall ist untergeordnetes Element von .element-a , wodurch der resultierende CSS-Code geändert wird. Seien Sie also vorsichtig mit Einrückungen!

Ich glaube, dass die einrückungsbasierte Syntax für ein Team, das hauptsächlich mit Ruby/Python arbeitet, attraktiver sein wird als für ein Team von PHP/Java-Programmierern (aber das ist nicht sicher).

Vorteile der SCSS-Syntax

Erstens ist es vollständig CSS-kompatibel. Das bedeutet, dass Sie eine CSS-Datei in .scss umbenennen können und sie funktioniert, als wäre nichts passiert.

Die vollständige Kompatibilität von SCSS mit CSS war seit der Veröffentlichung von SCSS immer eine Priorität für den Sass-Support, und meiner Meinung nach ist dies eine Stärke.

Sie versuchen auch, ein Auge darauf zu haben, was in Zukunft eine gültige CSS-Syntax werden könnte, und diese zu implementieren (daher @directives ).

Da SCSS mit CSS kompatibel ist, ist praktisch keine zusätzliche Schulung erforderlich. Die Syntax ist weitgehend gleich: Schließlich handelt es sich nur um CSS mit einigen Extras.

Dies ist wichtig für neue Entwickler, damit sie schnell mit dem Codieren beginnen können, ohne viel über Sass zu wissen.

Es ist auch besser lesbar, da die spezifischen Konstrukte bereits Sinn ergeben. Wenn Sie @mixin sehen, wissen Sie, dass es sich um eine Mixin-Deklaration handelt. Wenn Sie @include sehen, wissen Sie, dass es sich um einen Mixin-Aufruf handelt.

Es gibt keine Bedingungen und alles ergibt ohne Interpretation einen Sinn.

Auch fast alles vorhandene Werkzeuge, Plugins und Demos für Sass werden mit der SCSS-Syntax entwickelt. Diese Syntax orientiert sich immer mehr an Profis und wird von diesen standardmäßig gewählt (sofern es nicht die einzig mögliche ist).

Hauptsächlich aus den oben genannten Gründen. Beispielsweise wird es immer schwieriger, Hervorhebungen für die reine Sass-Einrückungssyntax zu finden. Im Allgemeinen sind nur SCSS-Hintergrundbeleuchtungsoptionen verfügbar.

Abschluss

Die Wahl liegt ohnehin bei Ihnen, aber wenn Sie keinen wirklich zwingenden Grund haben, eingerückte Syntax zu verwenden, würde ich dringend empfehlen, SCSS anstelle von Sass zu verwenden. Es ist nicht nur einfacher, sondern auch bequemer. Wenn Sie ein absoluter Anfänger sind, ist SCSS genau das Richtige für Sie. Die Ähnlichkeit mit CSS wird Sie nicht davon abhalten, das Layout mithilfe von Präprozessoren zu erlernen. Aber dann können Sie erwägen, Sass in Ihren Projekten zu verwenden. Die Hauptsache ist, keine Angst davor zu haben, neue Technologien in Ihrer Arbeit einzusetzen!

P.S. Bitte beachten Sie, dass Sass niemals mit einer Abkürzung in Großbuchstaben bezeichnet wird, unabhängig davon, ob es sich um eine Syntax oder eine Programmiersprache handelt. Während SCSS immer in Großbuchstaben angegeben wird.

Mir gefällt die SASS-Syntax aufgrund ihrer Kürze besser als die SCSS-Syntax. Aber die massive Verschachtelung von Stilen in SASS kann die Vorteile seiner Kürze schnell zunichte machen. Auf jeden Fall ist der Unterschied zwischen SASS und SCSS nicht grundlegend. Es stellte sich heraus, dass LESS näher an SCSS als an SASS lag. Und im Allgemeinen ist es dasselbe. Es gibt nicht viele Unterschiede, aber einige davon verändern die Machtverhältnisse grundlegend.

1. WENIGER – kann clientseitig mit JS erfolgen.

Genauer gesagt ist es nicht so, dass er es kann, er ist dafür geschaffen. Gängige Vorgehensweise bei der Verwendung von LESS-Code:

Zu diesem Zeitpunkt wurde die Möglichkeit hinzugefügt, auf dem Server zu kompilieren (sowohl js als auch Ruby).

Auf den ersten Blick scheint es eine seltsame Immobilie zu sein. Warum auf der Client-Seite kompilieren, wenn man auf dem Server perfekt kompilieren und fertiges komprimiertes CSS bereitstellen kann, wie wir es von SASS gewohnt sind?

Der Grund wird klar, wenn man die unscheinbaren allerletzten Zeilen der LESS-Dokumentation studiert:

@height: `document.body.clientHeight`;

Eine so kleine, einsame Linie bietet Möglichkeiten, von denen Layoutdesigner seit Beginn der Beherrschung von Stilen nur geträumt haben. Aufrufen eines clientseitigen Java-Skripts aus CSS und Berücksichtigung tatsächlicher Browsereinstellungen beim Erstellen von Stilen.

Das heißt, wir haben jetzt die Möglichkeit, zuerst das DOM zu laden und dann direkt auf der Clientseite spezielles CSS dafür zu erstellen. Dann überlegen Sie selbst, welche Chancen sich dadurch eröffnen.

Ob Ihr Projekt dies benötigt, ist eine andere Frage. Es ist klar, dass jeder an die Unsicherheit/Unabhängigkeit des Kunden gewöhnt ist und ein Layout im Stil von „Wir machen es universell, sodass es mehr oder weniger jedem bei allen Auflösungen gezeigt wird“ bietet. Dies ist jedoch kein Grund zu vergessen, dass jetzt eine solche Möglichkeit besteht und Sie damit beispielsweise ein sehr flexibles Layout erstellen können.

2. LESS hat im Gegensatz zu SASS/SCSS keine Logik.

In LESS gibt es kein Wenn/Dann, Für usw. Wenn man jedoch bedenkt, dass JS leicht darin integriert werden kann, denke ich, dass es durchaus möglich ist, die Logik einzubauen. Ich habe es nicht ausprobiert.

3. Das Mischen ist in LESS einfacher + Sie können Klassen mischen.

Besonders gut hat mir gefallen, dass man in LESS Eigenschaften anderer Klassen in die Definition einbeziehen kann. Die Klasse selbst ist ein Mixin. Dies ist eine weitere Funktion, die SASS/SCSS nicht bietet. Sie können eine reguläre CSS-Datei in LESS einbinden und deren Klassen zum Definieren Ihrer Eigenschaften verwenden. Zum Beispiel:

Wickeln (
Textumbruch: umbrechen;
Leerraum: vor dem Umbruch;
Leerraum: -moz-pre-wrap;
Zeilenumbruch: Wortumbruch;
}
pre ( .wrap )

Zusammenfassung

Mit Ausnahme des 1. Punktes ist der Unterschied nicht groß und die Auswahl für den Amateur größer.

Für mich persönlich sieht LESS aufgrund seiner Einfachheit attraktiver aus. Ich habe noch nie zuvor Zyklen und Bedingungen in Stilen benötigt. Klassische Dienstprogramme wie „Box-Shadow, Linear-Gradient, Darken“ sind in LESS verfügbar.

Ja, viele vorgefertigte Bibliotheken wurden bereits für SASS geschrieben (

• Übersetzung

„Welche Präprozessorsprache sollte ich für CSS verwenden?“ ist in letzter Zeit ein sehr drängendes Thema. Das wurde mir schon ein paar Mal persönlich gefragt, und es kommt mir so vor, als würde die Frage alle paar Tage online auftauchen. Es ist sehr schön, dass sich das Gespräch vom Thema der Vor- und Nachteile der Vorverarbeitung zu einer Diskussion darüber verlagerte, welche Sprache die beste ist. Machen Sie sich an die Arbeit!

Um es kurz zu machen: SASS.

Eine etwas lange Antwort: SASS ist in jeder Hinsicht besser, aber wenn Sie bereits mit LESS zufrieden sind, ist das cool, zumindest haben Sie Ihr Leben durch die Verwendung der Vorverarbeitung bereits einfacher gemacht.

Trainingsplan mit Ruby und der Kommandozeile Der einzige Punkt ist die Syntax. Um die von Ihnen erstellten Dateien zu kompilieren, sollten Sie eine Anwendung wie CodeKit verwenden. Sie müssen die Grundlagen von Ruby kennen bzw Befehlszeile oder etwas anderes. Das sollten Sie wahrscheinlich wissen, müssen es aber nicht, also spielt es keine Rolle.

Gewinner: keiner.

CSS3 zur Rettung Mit jeder der Sprachen können Sie Ihre eigenen Mixins erstellen, um das Leben mit Präfixen einfacher zu machen. Es gibt hier also keinen Gewinner. Aber wissen Sie, wie Sie die Aktualisierung dieser Präfixe in Ihren Projekten vermeiden können? (Nein, das wissen Sie nicht). Außerdem müssen Sie höchstwahrscheinlich Ihre eigene Mixins-Datei nicht aktualisieren. Mit SASS können Sie Compass verwenden, dessen automatische Updates dafür sorgen, dass Präfixprobleme der Vergangenheit angehören. Natürlich können Sie aktualisieren Software und kompilieren Sie es von Zeit zu Zeit, aber das ist eine triviale Aufgabe und Sie sollten sich nicht darauf einlassen.

Es läuft also alles darauf hinaus: SASS hat Compass und LESS nicht. Tatsächlich ist alles etwas komplizierter. Alle Versuche, ein Projekt wie Compass for LESS zu erstellen, sind gescheitert. Der Punkt ist, dass LESS nicht stark genug ist, um dies richtig zu machen. Etwas mehr Details weiter unten.

Gewinner: SASS

Sprachfunktionen: Mit Logic/Loops LESS können Sie „sichere Mixins“ erstellen. Diese Mixins werden nur wirksam, wenn die Bedingung wahr ist. Angenommen, Sie möchten die Hintergrundfarbe ändern, die von der aktuellen Textfarbe abhängt. Wenn die Textfarbe „hell genug“ ist, möchten Sie wahrscheinlich den Hintergrund dunkel machen. Wenn es „dunkel genug“ ist, benötigen Sie einen hellen Hintergrund. Auf diese Weise erhält man am Ende ein Mixin, das in zwei Teile geteilt ist, mit diesen „Wächtern“, die sicherstellen, dass nur einer von ihnen ausgeführt wird.

WENIGER
.set-bg-color (@text-color) wenn (Helligkeit(@text-color) >= 50 %) (Hintergrund: schwarz; ) .set-bg-color (@text-color) wenn (Helligkeit(@text.text -Farbe)< 50%) { background: #ccc; }
Nach der Verwendung erhalten Sie einen passenden Hintergrund:

WENIGER
.box-1 ( Farbe: #BADA55; .set-bg-color(#BADA55); )
Es ist sehr einfach, aber das Wesentliche ist hoffentlich klar. Man kann noch viel coolere Dinge machen. LESS ermöglicht auch selbstreferenzierende Rekursionen, deren Mixins sich selbst mit aktualisierten Werten aufrufen können.

WENIGER
.loop (@index) when (@index > 0) ( .myclass ( z-index: @index; ) // Ruft sich selbst auf .loopingClass(@index - 1); ) // Schleife stoppen .loopingClass (0) () // Gibt Sachen aus .loopingClass (10);

Hier enden die Logik/Schleifen in LESS. SASS verfügt über aktuelle logische und zyklische Operatoren. if/then/else, for-Schleife, while-Schleife und jede Schleife. Keine Tricks, echte Programmierung. SASS ist eine ziemlich robuste Sprache, die macht mögliche Verwendung Kompass.

Compass verfügt beispielsweise über ein Hintergrund-Mixin, das so leistungsstark ist, dass Sie alles hineinwerfen können, was Sie möchten, und am Ende genau das erhalten, was Sie möchten. Bilder, Farbverläufe und beliebige Kombinationen davon, durch Komma getrennt – und Sie erhalten das gewünschte Ergebnis (einschließlich Präfixen und allem anderen).

Ein lakonischer Code:

SCSS
.bam ( @include background(image-url("foo.png"), linear-gradient(top left, #333, #0c0), radial-gradient(#c00, #fff 100px)); )
Dieser Code verwandelt sich in das folgende Monster (was leider für die browserübergreifende Kompatibilität erforderlich ist):

CSS
.bam (Hintergrund: 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)); Hintergrund : url("/foo.png"), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px); Hintergrund: url("/foo .png"), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px); Hintergrund: url("/foo.png"), - o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px); Hintergrund: url("/foo.png"), -ms-linear-gradient( oben links, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px); Hintergrund: url("/foo.png"), linear-gradient(oben links, #333333, #00cc00) , radial-gradient(#cc0000, #ffffff 100px); )
Gewinner: SASS

Gewinner: WENIGER

@extend-Konzept Nehmen wir an, Sie haben eine Klasse mit einem bestimmten Stilsatz erstellt. Dann müssen Sie ein weiteres erstellen, das dem vorherigen ähnelt, jedoch einige Ergänzungen aufweist. Mit LESS können Sie es so machen:

WENIGER
.module-b ( .module-a(); /* Kopiert alles von .module-a hier unten */ border: 1px solid red; )
Im Wesentlichen handelt es sich hierbei um ein gewöhnliches „include“. Sie können diese Einfügung auch in SASS verwenden, besser ist es jedoch, @extend zu verwenden. @extend kopiert nicht nur die Stile von .module-a nach .module-b (was zu einer Aufblähung der Datei führt), sondern ändert auch den Namen des .module-a-Selektors in .module-a, .module-b in der kompilierten Datei CSS (was effizienter ist).

SCSS
.module-a ( /* Eine Menge Zeug */ ) .module-b ( /* Ein einzigartiges Styling */ @extend .module-a; )
Kompiliert zu:

CSS
.module-a, .module-b ( /* Eine Menge Zeug */ ) .module-b ( /* Ein einzigartiger Stil */ )
Siehst du das? SASS überschreibt Selektoren, was eine effizientere Methode ist.

Gewinner: SASS

Variablenverarbeitung: LESS verwendet @, SASS verwendet $. Das Dollarzeichen wird in CSS nicht verwendet, @ jedoch nicht. Es wird verwendet, um @keyframes oder @media-Blöcke zu deklarieren. Man denkt vielleicht, dass die Verwendung des einen oder anderen Sonderzeichens Geschmackssache ist, aber ich denke, dass SASS hier gerade deshalb einen Vorteil hat, weil es die Grundkonzepte nicht durcheinander bringt.

SASS hat eine seltsame Eigenschaft: Wenn Sie eine „globale“ Variable mit einer „lokalen“ überschreiben, nimmt die globale Variable ihren Wert an. Ein bisschen komisch.

SCSS
$Farbe:schwarz; .scoped ( $color: weiß; Farbe: $color; ) .unscoped ( // LESS = schwarz (global) // SASS = weiß (überschrieben durch lokale) Farbe: $color; )
Dieser Trick kann nützlich sein, ist aber überhaupt nicht intuitiv, insbesondere wenn Sie in Javascript schreiben.

Gewinner: Du musst eine Münze werfen :)

Arbeiten mit Medienregeln Fast jeder von uns, der anfängt, mit @media-Regeln zu arbeiten, fügt unten Blöcke mit diesen hinzu Startseite Stile. Das funktioniert, führt aber zu einer Stilentkopplung wie folgt:

CSS
.some-class ( /* Standardstil */ ) /* Hunderte Zeilen CSS */ @media (max-width: 800px) ( .some-class ( /* Responsive Styles */ ) )
Mit SASS oder LESS können Sie diese Stile durch Verschachtelung kombinieren.

SCSS
.some-class ( /* Standardstil */ @media (max-width: 800px) ( /* Responsive Styles */ ) )
„respond-to“ ist eine ziemlich coole SASS-Technik (sehen Sie sich den Code von Chris Eppstein, Ben Schwarz und Jeff Croft an).

SCSS
=respond-to($name) @if $name == kleiner @media-Bildschirm und (min. Breite: 320 Pixel) @content @if $name == großer @media-Bildschirm und (min. Breite: 800px) @content
Dann können Sie sie ganz prägnant verwenden:

SCSS
.Spaltenbreite: 25 % +Response-to-Breite (kleiner Bildschirm): 100 %
Hinweis: Um diese Technik nutzen zu können, benötigen Sie SASS 3.2, das sich derzeit in der Alpha-Phase befindet. Sie können es mit gem install sass --pre installieren. Ich denke, es sollte keinen Zweifel daran geben, dass dies eine wirklich nützliche Sache in der Entwicklung ist.

Gewinner: SASS

Mathematik Grundsätzlich ist der mathematische Teil beider Sprachen recht ähnlich, dennoch gibt es einige Kuriositäten im Umgang mit Maßeinheiten.
Beispielsweise nimmt LESS den Wert der ersten Variablen als Einheit und ignoriert alle anderen.

WENIGER
div (width: 100px + 2em; // == 102px (seltsam))
SASS wird Sie klar und deutlich darüber informieren, dass hier ein Fehler verborgen ist:
Inkompatible Einheiten: „em“ und „px“ . Natürlich ist es umstritten, was besser ist – ein Fehler oder ein falscher Wert, aber ich persönlich bin für ersteres. Insbesondere wenn Sie Variablen anstelle von Zahlen bevorzugen, ist es sehr schwierig, sie zu verfolgen.

Mit SASS können Sie mathematische Operationen an „unbekannten“ Maßeinheiten durchführen, die möglicherweise vor dem nächsten Update erscheinen. LESS erlaubt dies nicht. Es gibt noch seltsamere Unterschiede, etwa wie SASS Zahlen mit Einheiten multipliziert, aber das ist heute kein Thema.

Gewinner: SASS (mit einer gewissen Länge)

Vom Autor: Was ist ein Präprozessor? Kurz gesagt ist ein Präprozessor ein Programm, das Daten an die Eingabeanforderungen eines anderen Programms anpasst. CSS-Präprozessoren sind eine Skriptsprache, die die Fähigkeiten von regulärem CSS um Variablen, Verschachtelungsregeln, Funktionen und logische Blöcke erweitert.

Warum sollte ich es verwenden?

Oftmals befinden Sie sich in der Situation, dass Sie an verschiedenen Orten den gleichen Wert für eine bestimmte Immobilie ansetzen müssen. Beispielsweise haben Sie zunächst Rot als Primärfarbe der Site angegeben. Dann müssen Sie es auf Grün ändern.

Mit Variablen müssen Sie nicht jede Erwähnung von Rot in Stilen suchen und ersetzen. Sie definieren den Wert einer Variablen einmal, zum Beispiel „Primärfarbe“, und verwenden diese Variable dann als Wert.

Der Primärfarbwert ändert sich an einer Stelle. Sie können CSS-Dateien auch aus anderen Quellen importieren, ohne sich Gedanken über die Anzahl der Netzwerkanfragen machen zu müssen, da diese vor der Kompilierung alle in einer Datei zusammengefasst werden können.

Dank der verschachtelten Natur von CSS-Präprozessoren erhalten Sie kompakten Code mit demselben Ergebnis. LESS und SCSS basieren auf dem DRY-Prinzip, das für „Don’t Repeat Yourself“ oder „Wiederhole dich nicht“ steht.

Präprozessoren. Schneller Start

Was ist falsch an WENIGER?

Das Netzwerk ist bereits voller Diskussionen darüber, was besser ist: LESS oder SCSS. Daher werde ich nicht näher auf beide Themen eingehen. Stattdessen werde ich über die kleinen Probleme sprechen, die ich mit LESS hatte.

SCSS verwendet das $-Symbol zum Definieren von Variablen, während LESS das @-Symbol verwendet. Da CSS das @-Symbol auch für Medienabfragen, Importe und Keyframe-Animationen verwendet, kann dies für Entwickler verwirrend sein.

Das $-Symbol wird in CSS nicht verwendet. Das @-Symbol ist in SCSS vorhanden, wird jedoch für die Anweisungen @if, @else, @each, @for und @while verwendet.

Obwohl dieses Szenario nicht für jeden realistisch ist, ist es besser, unterschiedliche IDs zum Trennen von Elementen zu verwenden.

SCSS unterstützt traditionelle boolesche Ausdrücke wie if/else, Blöcke und Schleifen. Geschützte Mixins in LESS sind zwar optisch ansprechender, aber schwerer zu verstehen.

Kann mit WENIGER erreicht werden...

...oder einfach SCSS verwenden.

LESS definiert nur ein geschütztes Mixin. Daher können Sie nicht einfach das zweite Argument übergeben und es im selben Mixin verarbeiten, wodurch der Code für alle dupliziert wird mögliche Szenarien. Tatsächlich ist WENIGER (weniger) mehr (Wortspiel beabsichtigt).

Ich weiß, dass es in diesem Fall möglich ist, den Code zu kürzen, indem erweiterte Werte als Eigenschaftsnamen verwendet werden, aber das Problem besteht darin, dass ich nicht bedingt zwei verschiedene Teile desselben Mixins LESS zuordnen kann.

Es gibt noch mehr Kopfschmerzen mit diesem Code ...

Präprozessoren. Schneller Start

Lernen Sie in weniger als zwei Wochen die Grundlagen der Verwendung von Less- und Sass-Präprozessoren von Grund auf

...als damit.

Um mit LESS das gleiche Ergebnis zu erzielen, musste ich alles vordefinieren, ein Mixin schreiben, die Indexposition ermitteln, es mit meiner Logik durchlaufen, bis der Indexwert Null ist, und das Mixin manuell aufrufen.

Obwohl dies meine persönliche Meinung ist, denke ich, dass SCSS Berechnungswerte und mathematische Werte im Allgemeinen besser verarbeitet.

Was ist daran falsch?

LESS hingegen ist viel komplexer. Wenn ich es beispielsweise verwende, versuche ich nicht, Berechnungen durchzuführen. Aber selbst wenn ja, seit wann sind 100 % minus 50 Pixel gleich 50 %?

WENIGER, warum ignorierst du Werte mit Änderungseinheiten?

Warum zwingst du mich, deine Krücken zu lernen, wenn ich CSS bereits kenne?

Und noch eine letzte Sache. Dank des LibSass-Projekts verfügt SCSS über viele Wrapper für andere Sprachen wie C, Go, PHP, Python, Dart usw.

Warum haben wir uns entschieden, LESS zugunsten von SCSS aufzugeben?

Während wir JotForm Cards entwickelten, mussten wir Variablenwerte vorverarbeiten – Vorkompilierung und serverseitiges Caching gleichzeitig; und das alles musste perfekt gemacht werden.

Wir wollten, dass Benutzer Anpassungen vornehmen können Aussehen Formen Damit alle Änderungen sofort und gleichzeitig angezeigt und auf dem Server zwischengespeichert werden. Im Interesse unserer Benutzer wollten wir keine clientseitige LESS-Shell ausführen, da dies die Rechenleistung des Clients erfordern würde – und viele Dinge schief gehen könnten.

Wir haben den Entwicklungszyklus nicht mit dem Ziel begonnen, von LESS zu SCSS zu wechseln. Aber mitten in der Bewältigung dieser kleineren Probleme war das Fehlen einer anständigen Verpackung für LESS der letzte Tropfen, der das Fass zum Überlaufen brachte.

Allerdings sind die Unterschiede zwischen LESS und SCSS weniger wichtig als ihre Gemeinsamkeiten. Letztendlich spielt es keine Rolle, welchen Präprozessor Sie verwenden, solange Sie ihn verwenden.

Der Versuch, ein großes Projekt mit einer einzigen CSS-Datei und einer herkömmlichen CSS-Struktur zu verwalten, ist viel schwieriger als die Verwendung eines Präprozessors mit einigen Problemen.