LESS als Live-CSS Engine nutzen

In letzter Zeit wurde viel darüber gesprochen, LESS/Sass als Präprozessoren zu verwenden, um schneller und einfacher sauberes, browserübergreifend kompatibles CSS zu erstellen, als wir es bisher konnten. Und aus eigener Erfahrung kann ich Ihnen sagen, dass Sie, sobald Sie sich auf eine dieser Sprachen einlassen, so viel Spaß haben werden, dass Sie nicht mehr zum reinen CSS zurückkehren werden.

Das Problem mit diesen Sprachen ist jedoch das Wort 'Präprozessor'.

Die Idee eines Präprozessors ist, dass es diesen 'Verarbeitungsschritt' zwischen dem Code, den Sie schreiben, und dem Code, den Sie auf Ihrer Website verwenden, gibt. Das ist eine gewisse Mühe. Außerdem hindert es uns daran, Variablen oder Funktionen dynamisch zu nutzen, was nützlich sein könnte, wenn Benutzer die Darstellung Ihres Codes anpassen (wie bei einem WordPress-Theme).

Nun, die Live-Verarbeitung von LESS in der Produktion ist sehr gut möglich, und hier ist, wie wir sie verwenden, um einige große Probleme in unserem Unternehmen zu lösen.

Über PageLines

PageLines stellt ein „Drag-and-Drop“-Framework auf Basis von WordPress her, das die Erstellung professioneller Websites erleichtern soll.

Der Versuch, professionell und gleichzeitig einfach zu bleiben (typische Benutzer sollten *keinen* Code schreiben müssen), hat zu einigen technischen Herausforderungen geführt, bei deren Lösung LESS geholfen hat.

Anwendungsfall

Das PageLines-Framework basiert auf WordPress (in PHP). Bei der Prüfung dieser Lösung hatten wir mehrere Ziele. Zum Beispiel wollten wir

• CSS basierend auf Benutzereinstellungen innerhalb des Frameworks anpassen
• CSS besser organisieren und unterteilen, ohne die Leistung beeinträchtigende HTTP-Anfragen zu erhöhen
• bessere, browserübergreifend kompatiblere Designs schneller und einfacher erstellen, ohne sich mit einem neuen 'Vorverarbeitungs'-Schritt in unserem Workflow auseinandersetzen zu müssen

Warum LESS für Live-Verarbeitung? (Nicht SASS/Compass)

Chris schrieb einen interessanten Artikel über die Vorzüge von Sass vs. LESS. Es gibt jedoch ein paar Punkte, die für LESS bei der Live-Verarbeitung für uns den Ausschlag geben. Insbesondere wurde LESS in JavaScript entwickelt, *der* entwicklerfreundlichen Sprache, und wurde auch für die Live-Nutzung geschaffen. Am wichtigsten ist, dass es 6x schneller kompiliert als SASS. Jacob Thornton, Architekt des beliebten Bootstrap von Twitter, hat hier weitere Einblicke in die Debatte.

Während der ursprüngliche Live- Ansatz mit less.js in der Produktion zu viel Verzögerung aufweist, hilft er dennoch, LESS für die Verwendung in der Produktion anstelle als Präprozessor zu favorisieren. Wir haben letztendlich einen speziellen PHP-Port von Less.js verwendet, um unser Ziel zu erreichen, dazu gleich mehr.

Nebenbemerkung: Es ist theoretisch möglich, SASS 'live' zu verwenden, wenn Sie in einer Ruby on Rails-Umgebung entwickeln. Wir haben dies noch nicht getestet, daher bin ich mir über die Leistung oder Engpässe bei diesem Ansatz nicht sicher.

Wie wir es implementiert haben

Für uns war der Schlüssel zur Ausführung einer Live-LESS-Engine dieser Port des LESS-Prozessors nach PHP (Link), der es uns ermöglichte, LESS-Dateien basierend auf Benutzeraktionen auf unserem Server zu parsen und zu cachen. Um dies zum Laufen zu bringen, macht das Framework einfach Folgendes.

• Sammelt alle LESS-Dateien aus dem gesamten Framework und fügt sie einer PHP-Variable hinzu
• Verwendet das obige PHP-Skript, um LESS in CSS zu parsen und es in einer Variablen zu speichern
• Gibt das CSS in eine Datei aus, die sowohl auf dem Server als auch im Browser der Besucher gecacht wird
• Der Vorgang wird jedes Mal erneut ausgeführt, wenn ein Benutzer seine Einstellungen speichert oder eine neue Erweiterung installiert

Codebeispiel

Dies ist nicht der tatsächliche Code, den wir verwendet haben, sollte Ihnen aber eine allgemeine Vorstellung geben.

$parser = new lessc(); // Start new object from PHP Less script
$less_code = file_get_contents(‘/path/to/whatever.less’); // Grab LESS
$processed_css = $parser->parse($less_code); // Process to CSS
file_put_contents(‘path/to/css-file.css’, $processed_css); // Write CSS
echo “<link rel='stylesheet' href='http://url/to/css-file.css' type='text/css' media='all' />”; // Link CSS in page

Ergebnisse

Steuerung – Dynamische Farben und Typografie

Eines der coolsten Dinge bei der Implementierung von LESS im Framework ist, dass wir Farben und Typografie dynamisch basierend auf Benutzerauswahlen steuern können. Dies ermöglicht uns, Dinge gut zu gestalten und Benutzern gleichzeitig die Möglichkeit zu geben, Farben und Schriftarten anzupassen.

Optionen – LESS-Option für Benutzer

Benutzer können tatsächlich ihr eigenes LESS im Admin-Optionspanel hinzufügen. Sie können gängige Variablen für die Hintergrundfarbe oder Hauptschriftarten verwenden. Dies ist ein Feature, das Benutzer lieben und das sie zur Erstellung einer browserübergreifenderen, robusteren Anpassung des Frameworks nutzen können.

Organisation – Mehrere Dateien zu einer

Die Verwendung eines Prozessors für LESS ermöglicht es uns, alle unsere CSS/Less-Dateien nach Typ zu organisieren und sie dann zur Laufzeit zu einer einzigen 'kompilierten CSS'-Datei zusammenzufassen. Das macht es definitiv einfacher, das zu finden, was wir suchen.

Optimierung – Saubereres, schnelleres, browserübergreifend kompatibles CSS

Da wir verschachtelte Selektoren und Mixins verwenden können, ist der Code, den wir schreiben, viel sauberer. Das ist zwar dasselbe wie bei der Verwendung eines Präprozessors, aber die Tatsache, dass wir uns nicht mit dem Finden aller Dateien und dem Kompilieren herumschlagen müssen, ermöglicht uns die Nutzung ohne den Aufwand.