CSS-Präprozessoren

Roman Stranghöner: Hi, ich bin Roman. Ich arbeite bei der innoQ seit ca. 2 Jahren. Bin da im Bereich Frontend-Entwicklung und CSS und Präprozessoren unterwegs. Bin aber auch normaler Softwareentwickler und Consultant.

Stefan Tilkov: Noch echter Softwareentwickler.

Roman Stranghöner: Genau, genau. Ein Full-Stack-Entwickler oder wie das heute sich schimpft. Keine Ahnung.

Stefan Tilkov: Ok. Falk Hoppe ist auch dabei. Falk?

Falk Hoppe: Ja, die zweite Nase heißt Falk, genau hi. Ich arbeite auch seit ein paar Jahren bei der innoQ und bin auch in irgendwie allen Feldern der Softwareentwicklung zu finden - also von DevOps bis hin zu ganz viel Rails und Co. und mache auch total gerne Frontend.

Stefan Tilkov: Wir haben beim letzten Mal über CSS allgemein gesprochen und ich habe ein bisschen was gelernt über die Dinge, die mich schon immer wahnsinnig gemacht haben. Ein Thema haben wir extra ausgespart, nämlich Präprozessoren. Vielleicht kannst du, Roman, mal kurz erklären, was dass eigentlich ist und wofür man sowas braucht.

Roman Stranghöner: Also die Grundidee ist eigentlich, dass man - da es ja in CSS nicht sowas wie Variablen gibt oder Kontrollstrukturen oder sowas wie Ersetzung durch parametrisierte Listen oder sowas, sowas was eigentlich ganz nett wäre zu haben in CSS, da es im Moment halt einfach nicht drin ist, ist irgendwann mal so ein Trend dahin gegangen, das ganze quasi in einer anderen Sprache einmal durchlaufen zu lassen, in der man dann im Prinzip ein Overset von CSS schreiben kann, mit den gerade besagten Features noch oben drauf. Und dann lässt man das einmal durch so einen sogenannten Präprozessor durchlaufen und hinten raus wird dann CSS kompiliert.

Stefan Tilkov: Was wäre ein Beispiel für solche Präprozessoren? Es gibt ja ganz viele.

Roman Stranghöner: Es gibt - also der populärste so weit und breit ist eigentlich Sass, geschrieben von Hampton Catlin. Den gibt es schon richtig lange – ich weiß gar nicht – sieben, acht Jahre. Also der ist richtig alt.

Falk Hoppe: Ja, ewig. Auf jeden Fall.

Roman Stranghöner: Hampton Catlin ist – vielleicht auch bekannt – der Schlöpfer von HAML.

Falk Hoppe: Ja, furchtbar.

Roman Stranghöner: Da gibt es einmal Sass in zwei Dialekten, nämlich einmal als .sass-Files und als .scss-Files. Also es gibt auch – vielleicht sagt dem ein oder anderen auch scss was - das ist im Prinzip auch Sass, aber dass ist einer von zwei Dialekten von Sass. Und dann gibt es neben Sass, gibt es noch Less und Stylus, von denen ich, von beiden habe ich ehrlich gesagt keine Ahnung. Da kann Falk vielleicht gleich irgendwas zu erzählen. Ich nutze eigentlich nur Sass, weil es damals in dem Projekt, als ich begonnen hab mich mit der Materie auseinander zu setzen, war das ein relativ großes Rails-Projekt und in Rails – ich glaube ab Rails 3 – ist Sass einfach standardmäßig an Bord, in die Asset-Pipeline integriert und das ist eigentlich so der Einstieg. Die Einstiegsdroge, wo man das erste mal mit sowas in Berührung kommt.

Falk Hoppe: Also ich bin witzigerweise mit Less eingestiegen noch. Also das ist auch schon ewig her. Ich kann mich also ja gar nicht mehr erinnern. Also es ist wirklich schon lange her und damals war das absolute Pflicht eigentlich Less zu nehmen, weil Sass ja nur diesen blöden Sass-Dialekt hatte in der Tat. Und der lehnt sich halt an HAML an und ist halt whitespace- sensitiv und das fand man früher doof.

Stefan Tilkov: Das müssen wir vielleicht noch kurz erklären. Also HAML ist eine Syntax um HTML zu schreiben oder HTML-Templates zu schreiben, ohne dabei HTML zu schreiben. Also man schreibt seine eigene Syntax, die wie Python whitespace-sensitiv ist und wo man keine Tags schließen muss, sondern durch die Einrückung ergibt, was man gerade wieder zu macht. Und das ist meistens so, man hasst das oder man liebt das.

Falk Hoppe: Ja das Problem ist halt, das Generat aus HAML ist halt schon vorgefertigt und sagen wir mal ich pumpe aus einer whitespace-sensitiven Sprache pumpe ich irgendwie vorformatiertes oder beziehungsweise nach gewissen Regeln aufgebautes HTML raus. HTML ist aber selbst whitespace- sensitiv. D.h., ich muss dann an gewissen Stellen eigentlich ausbrechen können und das geht nicht so richtig. Also gegen HAML gibt es eigentlich gute Gründe. Bei Sass ist das eigentlich anderes. Da war das so ein bisschen vorurteilmäßig, aber grundsätzlich war Less halt eher die Sprache, die man meiner Meinung nach damals gewählt hat. Die konnten eigentlich damals ziemlich genau das gleiche. Es gab halt sowas wie: eine Variable in Less hat man mit einem @ definiert oder deklariert und in Sass war es ein $-Zeichen und ähnliche Geschichten. Aber im Grunde konnte die ziemlich genau das gleiche Feature-Stack, das ist heute halt ein bisschen anders. Und heute neige ich eigentlich auch eher zum Sass-Faktor.

Stefan Tilkov: Bevor wir vielleicht das machen: was war das Dritte noch? Stylus?

Roman Stranghöner: Stylus.

Falk Hoppe: Stylus. Genau Stylus. Da kann ich jetzt auch nicht so viel zu erzählen. Es ist relativ neu. Es ist erstmal, also es ist vielleicht ein minimaleres Set von Funktionen, würde ich gerade behaupten. Also ich weiß nicht, ob das schon alles mit mitbringt, was Sass so hat. Würde ich im Moment bezweifeln.

Roman Stranghöner: Ne, ich glaub nicht. Also das Feature-Set, das Sass hat, hat keiner der beiden.

Falk Hoppe: Ja, würde ich auch behaupten. Gerade so bei den neueren Features, wie Media-Queries und so, glänzt Sass also definitiv. Aber es ist vielleicht einen Blick wert. Aber es fehlen halt Frameworks, da kommen wir vielleicht später noch zu.

Stefan Tilkov: Dann erklärt vielleicht dennoch ganz kurz, warum oder was du gegen Less hast, warum du das jetzt ablehnst. Aus anderen Gründen, hattest du angedeutet.

Falk Hoppe: Ja, also es ist in der Tat. Also man hat, wenn man jetzt so ein Präprozessor-Framework einkauft, hat man halt eben nicht nur das Pr äprozessor-Framework vor dem Kopf, sondern man hat eine ganze Umgebung von möglicherweise fruchtbaren Frameworks, die man nutzen kann. Und da bietet Sass einfach wirklich den großen Umfang an und Less einfach viel, viel weniger. Also Less ist relativ beliebt, weil das möglicherweise leichter in gerade Nicht-Ruby-Sprachen einzubetten ist. Ich glaube aber, das ist ein reines Vorurteil, weil das natürlich – also so ein Präprozessor-Framework ist ein reines Development-Werkzeug. Das hat irgendwie, ob das jetzt in meiner Produktion wird das keine Abhängigkeit erzeugen. Ob ich das hab oder nicht, ich kann hinten raus normales CSS raus rendern oder tue ich natürlich auf jeden Fall. Und dementsprechend ist es eigentlich völlig egal, ob das jetzt in Ruby oder sonst was ist.

Stefan Tilkov: Vielleicht müssen wir das sagen. Ich glaube das zu wissen, aber ich bin mir auch nicht ganz sicher. Sass ist in Ruby implementiert und Less ist in JavaScript implementiert. Richtig? Oder es gibt einen Präprozessor, der in JavaScript implementiert ist, mit dem ich Less-Dateien in CSS-Dateien übersetze.

Falk Hoppe: Genau und dementsprechend kann ich das auch mit Rhino und Co. auch in der JVM halt.

Stefan Tilkov: Oder mit node.js auf dem Server.

Falk Hoppe: Genau, genau. Node.js ist auch der Standardweg.

Stefan Tilkov: Ah, ok. Aber ich kann Less auch im Browser theoretisch rendern lassen. Ich könnte theoretisch oder kann ich das nicht? Ich meine ich hätte das mal bei irgendeinem Tutorial mal gesehen.

Falk Hoppe: Ja, doch geht. Ich meine es gibt eine Library, die das hat. Ja. Ich meine das ist ähnlich wie diese CoffeeScript-Library, das es für CSS gibt.

Stefan Tilkov: Ok. D.h., das worüber ich durchaus nachdenken muss ist, wenn ich mich für eines dieser Frameworks – nein, Frameworks ist das falsche Wort – für einen dieser Präpozessoren entscheide, dann spielt durchaus auch die Umgebung eine Rolle. Es spielt eine Rolle, ob ich damit ein Problem habe, eine Ruby-Umgebung aufzusetzen oder nicht.

Roman Stranghöner: Ja, wobei…

Falk Hoppe: Wobei die eben halt nur für die Development-Kisten wichtig ist. Insofern – aber ist ein Gedanke.

Roman Stranghöner: Erwähnenswert ist vielleicht auch, dass der Hampton Catlin gerade auch an einer C-Implementierung von Sass arbeitet, also Lib- Sass. Und damit soll eigentlich dann das Thema Ruby auch vom Tisch sein.

Stefan Tilkov: Ok, weil das ja eigentlich eine Syntax ist, die irgendwie auf klar definierter Art und Weise spezifiziert ist, um daraus eben was anderes zu erzeugen. Und diesen Compiler/Interpreter/Transpiler kann man natürlich mit irgendwas erzeugen. Ok, gut. Ja dann lasst uns doch, weil es das ist, womit ihr euch am besten auskennt, vielleicht im Sass oder Scss einsteigen. Was neben wir da jetzt? Was ist der Unterschied nochmal, zwischen diesen beiden Formaten?

Roman Stranghöner: Ja, also es sind im Prinzip zwei ja Dialekte oder zwei Geschmacksrichtungen, wie man das denn schreiben kann. Ich hab ja eben versucht zu erklären, dass man mit Präprozessoren so ein paar mehr Features hat, als in CSS selbst. Scss, als einer der beiden Dialekte, hat den Charme – und das ist meistens auch das, womit Einsteiger beginnen –, dass ich da drin ganz normal CSS schreiben kann. Also CSS ist ganz valides Scss. D.h., ich fang am – wenn ich damit anfange, beginne ich eigentlich damit erstmal die Dateiendung zu ändern. Also wenn ich mein CSS-File hab, dann kann ich einfach dahinten ein “.scss” hinten dran hängen, lass das über mein Sass drüber jagen und ich habe im Prinzip das selbe Resultat, was jetzt im Moment natürlich noch etwas witzlos ist. Aber dann kann ich quasi anfangen und alle netten Features, die Sass als Präprozessor mitbringt, darin benutzen. Und “.sass” – im Unterschied zu “.scss” – ist auch ähnlich wie HAML so eine whitespace-sensitive Syntaxschreibweise. Und von ein und den selben Features.

Falk Hoppe: Aber ich spare halt eine Unmenge von Klammern und ähnliches. Also der Vorteil von “.scss” ist halt definitiv: wenn ich bestehendens CSS habe, ist das viel viel schöner zu vereinheitlichen. Bei “.sass” ist halt natürlich eben: da gelten alle Vorteile, die halt eben auch für Python sprechen, sage ich jetzt mal. Und alle Nachteile, die für Python sprechen. Aber mittlerweile würde ich sogar beinah eher wieder zu “.sass” tendieren. Also auch wenn das früher mein Grund war zu sagen: “Ich mache Less.”, weil ich…

Stefan Tilkov: Du bist irre.

Falk Hoppe: Genau, aber mittlerweile bin ich da sehr – ich habe vielleicht durch CoffeeScript. Also CoffeeScript und Sass sind irgendwie. Das greift mittlerweile ziemlich gut ineinander. Also man schreibt halt beides whitespace-sensitive Sprachen, man hat halt beide Transpiler quasi, die sich sehr ähnlich verhalten. Also ich finde es eine sehr sehr gute Kombi.

Stefan Tilkov: Zu CoffeeScript müssen wir vielleicht ganz seperat nochmal reden.

Falk Hoppe: Ja! Aber das spricht gut ineinander.

Stefan Tilkov: Gut. Was sind denn so Features, die ich dann habe? Also erstmal würde ich mich ja mal als Skeptiker outen und sagen: Jetzt komme ich mit irgendwas anderem an. Jetzt habe ich mich gerade dran gewöhnt, dass CSS ganz toll ist und habe verstanden, wie das position-Ding funktioniert und jetzt soll ich mit irgendeiner anderen Sprache kommen, die nicht standardisiert ist und bei der ich mich vielleicht von irgendeinem Tool abhängig mache. Also was sind denn Gründe, sowas zu tun? Was habe ich für Vorteile davon?

Roman Stranghöner: Der allerbeste Grund ist eigentlich – oder aus meiner Sicht sind definitiv Variablen. Das ist so das erste, was einem eigentlich so in den Sinn kommt, wenn man anfängt CSS zu schreiben. Also alleine Farben irgendwie – diese Hex-Codes, die man da durch die Gegend kopiert wie ein Wahnsinniger und dann auf einmal merkt man: “Oh, das ist jetzt doch nicht der Blauton, den ich eigentlich wollte.” Und dann fängt man an im Prinzip den Hex-Code zu ändern – durch Suchen und Ersetzen – und das quasi jedes Mal, wenn einem der nicht gefällt. Das ist ein Beispiel, aber es gibt super viele Beispiele, wo Variablen das Leben einem schon erleichter würden – was auch eine der Gründe ist, weshalb das mit in die nächste Spec eingehen wird.

Stefan Tilkov: In die nächste CSS-Spec.

Roman Stranghöner: Genau, genau, ja. Neben Variablen gibt es – was machen wir denn da als nächstes?

Falk Hoppe: Also ganz wichtig finde ich ja nesting – also dass ich grundsätzlich erstmal CSS-Regeln verschachteln kann. Also man hat ja bei CSS-Files immer diese kilometerlangen Dateien eigentlich gehabt, die dann beliebig lange Selektor-Ketten vor sich hertragen. Also ich muss ja dann für diese Spezifitätserhaltung, die wir ja im letzten Podcast schon besprochen haben, muss ich natürlich sehr sehr lange Selektor-Ketten mit mir führen und bei Sass kann ich “nesten”. Also ich kann im Prinzip da…

Stefan Tilkov: Verschachteln.

Falk Hoppe: Genau, also ich kann im Prinzip diese Selektor-Ketten aufspalten und kann in Klammern verschachteln und kann eben sagen: “Das hier ist eine Unterregel von der Regel oben.” und hinten rauskompiliert wird dann die komplette Selektor-Kette. Das ist also sehr sehr angenehm.

Roman Stranghöner: Wobei man da auch aufpassen sollte, dass man es nicht übertreibt.

Falk Hoppe: Definitiv, also klar. Wie bei allem Guten, gibt es auch hier wieder…

Roman Stranghöner: Spezifität greift auch da: wenn ich zu viel “neste” habe ich tendenziell das selbe Problem wie in CSS auch, wenn ich meine Selektoren überspezifiziere.

Falk Hoppe: Ein anderer Punkt, um halt diese langen Spagetti-Code-CSS-Files aufzuhebeln, ist halt, dass man ein schönes import-Statement hat. Also Import hat bei CSS ja den Nachteil, dass ich pro Import, den ich auslöse, auch einen HTTP-Request auslöse. Und das möchte man natürlich nicht. Wenn man jetzt nicht so eine CSS-Komprimierung vorgenommen hat und vorher die CSS-Dateien zusammen gebaut hat, dann hat man natürlich keinen Vorteil von dieser Modularisierung, die man haben möchte. Bei “.scss” bzw “.sass” kann man hingehen und diese Import, die man – also Import von anderen Fremddateien, die ich importiere, möglicherweise auch Vendor-Libraries – kann ich benutzen um bzw. werden aufgelöst beim “transpilen”. D.h., ich habe nachher trotzdem nur eine Datei, die rausgerendert wird.

Stefan Tilkov: Wie ist das, mein Sass-Präprozessor übernimmt sozusagen diesen Job gleich mit.

Roman Stranghöner: Genau.

Falk Hoppe: Genau.

Stefan Tilkov: Um mir da ein optimiertes Ding rauszuwerfen.

Falk Hoppe: Und ich kann halt auch auf die Sachen zugreifen. Ich kann z.B. Variablen in einem anderen Sass-File definieren und dann auch darauf zugreifen.

Stefan Tilkov: Ich war gerade verwirrt, Roman, als du gesagt hast “Kontrollstrukturen” plötzlich? Was haben Kontrollstrukturen in sowas wie CSS verloren?

Roman Stranghöner: Man kann Schleifen bauen, wenn man das möchte.

Stefan Tilkov: Warum könnte ich das wollen?

Roman Stranghöner: Wenn man. Also ein sehr nettes Beispiel ist z.B.: auf unserer neuen innoQ-Webseite gibt es unten so einen Farbbalken. Und es gibt – man muss dazu sagen – es gibt sowas wie Listen in Sass als Datenstruktur. Und über diese Listen kann ich natürlich drüber iterieren und dann kann ich im Prinzip innerhalb meiner Schleife so etwas sagen wie “Entweder ich mache jetzt aus denen…” – also ich habe jetzt meine Liste und da sind z.B. ist jetzt unsere Farbpalette drin, als Variablen. Und in diesen Variablen stecken im Prinzip die Farb-Hex-Codes. Und dann iteriere ich über alle die Farben, die da in unserer Farbpalette drin sind und dann setze ich z.B. beliebige Properties, wie z.B. setze ich für den Hintergrund so ein linear- gradient und den lasse ich dann so aussehen, dass er im Prinzip diesen Farbbalken hinzaubert. Also dieses über Listen drüber iterieren und dann im Prinzip mit den Dingen irgendwas tun, über die man iteriert, das mag einem erstmal ein bisschen befremdlich vorkommen, aber also wenn man das ein Mal gemacht hat, erkennt man erst, dass es relativ nützlich ist bei diversen Dingen.

Falk Hoppe: Ja, ein schönes Beispiel sind vielleicht auch noch – man hat ja klassischerweise immer sowas, wie: “Ich habe 15 Buttons, die alle kleine Unterschiede haben.” Und dann hat man gern mal sowas gehabt, wie “Button 1, 2, 3, 4 usw.” Also den Klassiker, den man auch früher in der Programmierung am Anfang gemacht hat. Diese for-Schleife, die wird völlig überbewertet.

Stefan Tilkov: For-Schlaufe.

Falk Hoppe: Eine For-Schlaufe. Ich schreibe das einfach mal untereinander, ich kopiere das eben, kein Problem. Und man hat dann eben auf einmal 30 Zeilen Code, die man maintainen muss, wo man vorher nur eine oder bzw. drei hatte. Und genau das gleiche kann man halt eben auch machen, man kann diese in den Selektor-Namen kann man halt eben Ersetzungen dann vornehmen für diese Schleife.

Roman Stranghöner: Das klappt vor allen Dingen nicht nur für irgendwelche Properties oder so, also dass man einfach im Prinzip den Wert aus der Liste nimmt und als Propertie setzt, sondern man kann im Prinzip auch Klassen damit generieren.

Falk Hoppe: Ja das war das, was ich meinte, das sind diese Selektoren quasi.

Roman Stranghöner: Man kann simple Textersetzung damit machen, das ist schon ziemlich cool.

Stefan Tilkov: Was sind Mixins?

Falk Hoppe: Möchtest du, soll ich?

Roman Stranghöner: Also Mixins und Extends, das sind im Prinzip – also ein @extend und ein @include und eine Mixin, das sind zwei verschiedene Konzepte, die im Prinzip einem ermöglichen – fangen wir mit dem Mixin an –, dass man beliebige CSS-Blöcke parametrisieren kann. Also man kann sich das so vorstellen, wie – ja also man hat, man gibt in dieses Mixin Parameter rein, die man quasi ändern möchte, und dann hat man innerhalb des Mixin – also in dem Body – beliebiges CSS drin stehen und ersetzt dann im Prinzip die Parameter.

Stefan Tilkov: Wie ein Partial sozusagen.

Roman Stranghöner: Wie ein Partial, genau.

Stefan Tilkov: Wie ein Template oder ein parametriertes Template.

Roman Stranghöner: Wie ein Template. Mit dem Unterschied, dass das quasi eine reine Textersetzung ist.

Falk Hoppe: Ja, es ist wir beim Partial eigentlich.

Roman Stranghöner: Also der nimmt dann halt wirklich den ganzen Textblock und fügt den dann halt irgendwo ein mit den entsprechenden Werten. Da kann man dann auch einen Default setzen für die einzelnen Parameter. Da kann man relativ viel abgefahrenes Zeug mit machen. Man muss sich halt klar machen, dass es wirklich immer eine komplette, also dass immer der komplette Block an dem, was da in dem Body von dem Mixin drin ist, irgendwo rein gesetzt wird. D.h., wenn ich es übertreibe kann ich damit halt relativ schnell mein CSS auch aufblähen. Man sollte z.B. ein Mixin niemals dafür benutzen – man kann das leider – da keine Parameter reinzugeben, sondern im Prinzip das Mixin nur als, wie so eine Propertie-Liste, die statisch ist, durch die Gegend zu kopieren. Dafür würde man dann z.B. eher ein Extend benutzen. Das ist quasi die etwas schlauere Variante davon, die nämlich dann im Nachzug auch hergeht und Selektoren quasi in Rules zusammen packt und die dann alle die selbe, den selben Block quasi… Also der Block, der in dem Extend drin steht oder der in der Klasse drin steht, der wird dann nur ein Mal eingesetzt. Dann wird davor die Rule gesetzt, die Selektor-Liste. Und die erben quasi alle dieselben Properties. Es wird nur einmal…

Falk Hoppe: Die Selektor-Unterstützung, die Selektor-Kette quasi.

Stefan Tilkov: Wenn ich in zehn verschiedenen Selektoren dasselbe Extend drin habe, dann kommt am Ende eine CSS-Regel raus, die das aufsummiert. Die Union sozusagen aus all diesen Selektoren.

Falk Hoppe: Genau. Und beim Mixin hättest du halt zehn Blöcke sozusagen.

Roman Stranghöner: Wobei es auch – bei dem Extend muss man ein bisschen aufpassen. Wenn man im Prinzip in seinem, sagen wir mal in dem Block oder in der Klasse, die man da quasi aufmacht, wenn man es da zu wild treibt, kann das auch relativ schnell kaskadierend nach hinten los gehen. Also je nachdem, wenn ich innerhalb meines Moduls oder meiner Komponente oder was auch immer irgendwas extende und je nachdem, was ich da extende sind nochmal irgendwelche – ne bzw. alle Submodule, die an dieser Komponente dran hängen, erben das auch. D.h., wenn ich z.B. will, dass ein bestimmter Block an Properties nur an meine, an die eine Komponente quasi geerbt werden, wo ich das eigentlich möchte, dann würde man eher sowas wie einen Placeholder- Selektor nehmen. Das ist im Prinzip nochmal eine bisschen andere Schreibweise, da würde man dann so einen Prozent-Name des Selektors nehmen und das ist dann wirklich nur: “Das Ding wird nur ein Mal eingesetzt in der eigentlichen Komponente und alle Subkomponenten die ich bilde erben das nicht auch automatisch.”

Falk Hoppe: Also man muss auf jeden Fall, also sagen wir so, man sollte dieses Extend und Mixins auf jeden Fall auch wieder nur verwenden, wenn man weiß, was es tut, weil es halt definitiv…

Roman Stranghöner: Genau. Es bietet alles sehr sehr große Möglichkeiten, aber man muss wirklich aufpassen, was man tut, damit man halt das CSS- Generat nicht…

Falk Hoppe: Aber das ist halt wirklich Templating. Also ganz klassisch mit allen Vor- und Nachteilen. Es gibt halt auch noch functions, die kein Template zurückliefern, sondern halt, die ähnliches tun, aber dann halt eben Werte zurückliefern.

Roman Stranghöner: Werte, ja.

Falk Hoppe: Also ich kann dann halt auch irgendwelche Num-Values berechnen oder sowas oder Farb-Values.

Stefan Tilkov: Und die kann ich wahrscheinlich dann in Ruby programmieren, oder?

Falk Hoppe: Ne, die schreibt man dann auch in dem Sass-Code.

Roman Stranghöner: Ne, in Sass.

Falk Hoppe: Also man hat auch sowas wie Operatoren, also man kann z.B. hingehen und Farbwerte berechnen und addieren, multiplizieren und sowas.

Roman Stranghöner: Das sind auch sehr beliebte Dinge, die auch in Sass schon mit drin sind. Also so Standard-Basis-Funktionen sind da mit drin, wie z.B., dass man zu einer – es gibt eine lighten- und eine darken-Funktion, da kann man im Prinzip eine Farbe rein werfen und der berechnet dann…

Stefan Tilkov: Prozente oder sowas.

Roman Stranghöner: …genau, mit einem Prozentsatz und dann berechnet der im Prinzip auf dem Hex-Code die dunklere oder hellere Farbe. Es gibt relativ viele Funktionen, die man sich auch noch von irgendwelchen schlauen Köpfen importen kann, die dann alles mögliche abgefahrene Zeug von Mathe über oder generell über mathematische Funktionen, die man z.B. für Grids und sowas braucht, die das alles schön total nett wegkapseln und die holt man sich dann einfach rein und dann kann damit sehr abgefahrene Dinge tun.

Falk Hoppe: Hmhm, sehr cool, ja.

Stefan Tilkov: Wie passt das Thema “Präprozessoren” zu den Architektur- Konzepten, die wir beim letzten Mal drinne hatten? Ergänzt sich das gut oder ist das ein Update?

Falk Hoppe: Also definitiv, also grundsätzlich ja natürlich schon mal dadurch, dass man diese ganze Modularisierung viel viel einfacher hat. Und man so ein bisschen aus dem Vollen schöpfen kann, weil man halt eher eine Programmiersprache vom Gefühl her unterm Heck hat, also man Vererbung z.B. wirklich hat bei solchen Dingen. Also ich kann Komponenten voneinander erben lassen oder ich kann eben diese Mixins benutzen, um halt dieses – also sowas wie DRY kriege ich viel viel sauberer hin, wenn ich halt Mixins und Extend ordentlich verwende. Und ganz ganz viele andere Dinge kann ich im Prinzip mit – also sobald ich eigentlich so ein Sass oder ein Präprozessor unterm Hintern hab, habe ich halt wirklich eher eine Programmiersprache da, als es CSS vom Gefühl her ist.

Stefan Tilkov: Ist es universell gut? Also hab ihr da überhaupt – ihr habt da überhaupt keine Skepsis, ne? Ihr findet das total super.

Falk Hoppe: Also meiner Meinung nach möchte man kein Projekt mehr ohne machen, definitiv.

Roman Stranghöner: Aber wie gesagt – meine Bedenken gerade – die sollte man sich durchaus zu Herzen nehmen. Also man sollte wirklich sich – gerade wenn man damit anfängt – gucken, was das Ding generiert, damit man direkt sieht, wenn man da Unsinn macht. Wenn man halt wirklich es zu doll treibt, sowohl was das “Nesting” angeht als auch was die falsche Benutzung von Mixins und Extend angeht, dann kann es sehr schnell passieren, dass man so ein Blow-out CSS-Zeug produziert, was man dann eigentlich nicht haben will. Es gibt aber, wenn man damit anfängt, gibt es eine ganz nette Webseite, die heißt <sassmeister.com> glaube ich. Da kann man quasi in der linken Seite das “scss” oder “sass” oder was auch immer schreiben und recht sieht man gleich das Kompilat, was raus fällt. Und da kann man erstmal ein bisschen mit rum probieren und diese ganzen Features, die wir gerade genannt habe, einfach erst einmal das rein tippern und dann gucken, was da hinten raus fällt. Und da sieht man schon relativ schnell, wenn man es halt zu doll treibt, dann explodiert das Generat sehr schell.

Falk Hoppe: Und es ist halt so ein bisschen wie bei CSS, ne? Also wenn ich nicht damit arbeite und es einfach benutze und einfach auch jedes Feature rein werfe, ohne wirklich zu verstehen, was ich da tue, dann ist es wieder schlecht. Und das CSS wird dadurch natürlich auch nicht leichter. Also man muss natürlich vorher auch wieder CSS gelernt haben. Also es fällt jetzt nicht einfach raus, dadurch dass ich jetzt Sass benutze, wird das “Positioning” einfacher, oder ähnliches.

Stefan Tilkov: Und das Tooling? Also beim letzten Mal habt ihr erwähnt, dass ihr z.B. die Browsertools, die DevTools von Chrome oder so Webkit benutzt, um mit dem CSS rum zu spielen. Wie funktioniert das, wenn man Sass benutzt?

Roman Stranghöner: Bis für kurzem hat das gar nicht funktioniert.

Falk Hoppe: Genau.

Roman Stranghöner: Also man hat nach wie vor nur das CSS gesehen, also das Generat und da konnte man dann nach wie vor drin rumspielen, aber das hatte dann natürlich den blöden Nebeneffekt, dass man im Prinzip nicht die richtige Stelle editiert, sondern man muss dann quasi im Kopf haben “An welcher Stelle in meinem Sass-Code ist das eigentlich?” und dann muss ich diese Änderung quasi wieder mit zurück schlüren. Und mittlerweile – ich weiß gar nicht in welcher – in irgendeiner der letzten Chrome-Versionen haben sie Support für Sass eingebaut.

Falk Hoppe: 28.

Roman Stranghöner: Es ist im Moment noch ein experimantal feature, das muss man sich speziell freischalten. Dann muss man darüber hinaus eine spezielle Sass-Version nehmen, nämlich die 3–3-alpha. Die kann nämlich source maps.

Stefan Tilkov: Über JavaScript.

Roman Stranghöner: Genau. Und damit komme ich dann quasi wieder zurück in mein eigentliches .sass- bzw. .scss-File und kann dann da den gleichen Heckmeck machen, wie in meinem CSS auch.

Stefan Tilkov: Ok, also d.h., dass im Prinzip die Information, aus welcher Sourcecode-Zeile Sass, welche CSS-Zeile entstanden ist, die wird sozusagen mit transportiert?

Roman Stranghöner: Genau.

Stefan Tilkov: Ok, und darüber kann dann der Browser natürlich sagen…

Roman Stranghöner: Das ist natürlich noch relativ experimental und halt, wenn man sowas wie Rails benutzt mit der Asset-Pipeline, wo also die Asset- Pipeline einem das kompilieren abnimmt, dann verkompliziert das natürlich nochmal Dinge.

Falk Hoppe: Ja also, im Moment ist es halt auch “broken”. Also im Moment kann es auch wirklich, ist es gerade mal wieder nicht funktional. Aber es kann auch an meiner persönlichen Umgebung liegen. Das ist immer ein bisschen, natürlich jetzt bei diesem gerade – Chrome experimental DevTools, das sagt irgendwie schon alles. Aber es ist natürlich jetzt, also dadurch, dass es jetzt einfach schon in der Alpha-Release ist – die Release-Frequenz ist relativ kurz bei Sass – ist es wirklich glaube ich relativ schnell zu erwarten, dass es auch wirklich voll umfänglich da ist. Also bei CoffeeScript funktioniert es ja auch schon komplett. Da ist es super und ich denke, dass es jetzt auch bald das funktioniert.

Stefan Tilkov: Gibt es abgesehen vom Chrome-Browser den DevTools denn noch weitere Tools, die man einsetzen kann, wenn man mit Sass arbeitet?

Roman Stranghöner: Also eigentlich haben wir oder ich hatte eben erwähnt, dass das relativ einfach ist, das ganze in Rails zu benutzen, weil einem da diese Asset-Pipeline dieses ganze Kompilieren abnimmt. Also in dem Sinne kann man Rails im Prinzip als Tool ansehen, wenn man möchte. Man kann Sass aber auch komplett unabhängig von Rails eigentlich benutzen. Also wenn man jetzt ein relativ einfaches plainess HTML schreiben möchte und dadrin seinen CSS rein pumpen möchte, dann kann man das mit der Konsole – also Sass ist eigentlich ein Kommandozeilen-Tool, was ich aufrufen kann. Und ich übergebe dem in der Regel zwei Parameter, nämlich “wo liegt das Zeug, dass – wo liegen meine .sass-File oder meine .scss-Files” und “wo soll das ganze hin generiert werden”. Und das sind die beiden Dinge. Und da kann man halt noch diverse andere Sachen mit machen, aber eigentlich ist das relativ, ja sagen wir mal so: für Leute, die jetzt vielleicht nicht so Kommandozeilen-affin sind, ist das eigentlich schon fast ein No-Go, irgendwie sowas machen zu müssen. Da gibt es relativ viele Tools, die einem das abnehmen. Also wenn man da eine Einstiegshürde hat, was die Benutzung der Kommandozeile angeht, kann man sowas wie CodeKit für den Mac benutzen. Es gibt auch glaube ich irgendeinen Port mittlerweile für Windows-Systeme und ich glaube für Linux, aber die nehmen sowieso die Kommandozeile.

Stefan Tilkov: Wisst ihr irgendwas in Sachen IDE-Integration oder so für die Java-Welt? Gibt es irgendwie eine Eclipse oder IntelliJ IDEA Sass Integration?

Roman Stranghöner: IntelliJ kann auf jeden Fall Sass.

Falk Hoppe: Ich glaub auch Eclipse und auch NetBeans.

Roman Stranghöner: Die sind auch mittlerweile so pfiffig, dass man diesen Jump-to-Source, das kriegen die hin. Zumindest wenn alles in einem Projekt liegt. Ich glaube außerhalb wird es schwierig. Aber die erkennen schon diverse Dinge. Also auch wenn man dieses beliebe Strg+Leertaste-Pattern klappt da ganz gut, wenn man irgendwie – also der erkennt schon, was man da so geschrieben hat und schlägt einem Dinge vor. Das ist schon ganz nett.

Stefan Tilkov: Du hast vorhin, Falk, erwähnt, dass ein Grund, warum du Sass gegenüber Less bevorzugst, die Menge von Dingen sind, die darauf aufsetzen. Irgendwelche Frameworks, die darauf aufsetzen. Was wäre denn ein Beispiel für Dinge, die auf Sass aufsetzen und du dann auch benutzt.

Falk Hoppe: Also das Framework benutze ich ja halt, womit man heute gar nicht mehr rum kommt, ist Compass. Das ist eigentlich primär so ein bisschen ins Spiel gekommen, als es diese ganzen CSS3-Properties gab, die man so haben möchte. Also diese ganzen Fähigkeiten, bei denen ich einbeziehen muss, wenn ich die benutze – nehmen wir mal sowas wie “border-radius” oder sowas – dass die am Anfang nur Browser-spezifische Properties da waren. D.h., ich hatte sowas wie einen “webkit”-Präfix, ein “moz”-Präfix und ähnliches und Compass ist da um die Ecke gekommen und hat gesagt: “Pass mal auf, du kannst einfach bei uns ein Mixin benutzen und wenn du dieses Mixin benutzt, dann rendern wir die die Browser-Präfixe für border-radius.” Damit hat das eigentlich so ein bisschen angefangen und mittlerweile ist es aber so, dass es zu einer sehr sehr mächtigen Library geworden ist, die einem sehr sehr viel Funktion bringt. Also auch ganz viel, um Dinge zu berechnen, um Media- Queries z.B. sauber und ordentlich…

Stefan Tilkov: Oder auch Responsive Design, sagtest du beim letzten Mal.

Falk Hoppe: Genau, also ganz ganz viel Zeug. Hast du noch konkret Beispiel?

Roman Stranghöner: Unter anderem ganz nett: du hattest mit Till in der ersten Folge über Sprites gesprochen. Diese Tapeten, die man benutzt, idealerweise benutzt um Requests zu sparen. Ich glaube ihr hattet noch so ein bisschen Witzchen drüber gemacht, dass das eigentlich so Arbeit ist, die man nicht machen will. Weshalb das Internet scheiße ist, oder so.

Stefan Tilkov: Das kann schon gut sein, ja.

Roman Stranghöner: Und genau das nimmt einem Compass ab. Also das ermöglicht einem, einzelne Images irgendwo hinzulegen und dann sorgt Compass im Prinzip dafür, diese Tapete zu erstellen und einem zusätzlich noch CSS-Selektoren zu generieren, mit denen ich im Prinzip genau die richtige Position auf der Tapete quasi auf dem Präsentierteller bekomme. Also ich extende nur noch dieses eine, diese eine einzige Klasse und habe direkt alles erschossen.

Stefan Tilkov: Ich verstehe das, aber wenn die Zuhörer mich Kopfschütteln sehen könnten, ich bin trotzdem ziemlich erschlagen von der Komplexität, die da drunter steckt. Also was da eigentlich passiert ist ja, dass ich einen Präprozessor benutze, um CSS zu erzeugen, mit dem da etwas gemacht wird, sodass ich mich nur noch um HTTP-Requests zu sparen, indem ich Bilder zu Großbilder zusammen packe, die ich auf der Client-Seite dann mit splicing auseinander pfücke und alles nur, weil der Overhead, der HTTP-TCP-Connection so groß ist. Also da finde ich den Weg mit HTTP2 deutlich angenehmer.

Falk Hoppe: Wobei, ich pflücke die nicht auseinander auf Client-Seite. Ich verschiebe die.

Stefan Tilkov: Ne, du pflückst die nicht auseinander, du verschiebst die. Ja, aber das ist doch eigentlich absurd. Das ist ja nicht wirklich, das ist ja nicht schön!

Roman Stranghöner: Ja, ja, ja.

Falk Hoppe: Ja, ja.

Stefan Tilkov: Es will mir keiner sagen, dass das so gewollt ist.

Falk Hoppe: Nein, also das auch sowas wie…

Stefan Tilkov: Genau, wir haben gesagt, das ist ein typisches Beispiel, ein typischer Grund, warum Leute das Internet doof finden. Äh, das Web doof finden, weil man solche Sachen da macht.

Falk Hoppe: Aber Compass macht das einem sehr leicht.

Roman Stranghöner: Absolut.

Stefan Tilkov: Compass macht diesen Hack erträglicher.

Roman Stranghöner: Genau, weil man halt nicht – man muss die Tapete nicht neu setzen und man kann halt einfach Bildchen ändern und dann macht der das alles auto-magisch.

Stefan Tilkov: Das ist pragmatisch, also das kann man glaube ich sagen. Das ist ein pragmatischer Weg, genauso wie für diese hässlichen Vendor-Präfixe bei den CSS-Selektoren, weil ich dann irgendwie zehn oder 20 ineinander generiere, dass das gleich ist für “moz” und “web”…

Falk Hoppe: Es sind sogar nur fünf, aber es ist …

Stefan Tilkov: Schön ist das nicht und wenn einem der Präprozessor, das Framework den Punkt abnehmen kann, verstehe ich. Ja ok, also Compass wäre – um jetzt ganz wagemütig eine Analogie zu machen – ein bisschen so wie ein JQuery oder so in der JavaScript-Welt, das bügelt mir in gewisser Weise mal die Unebenheiten weg, sodass ich mich darum nicht kümmern muss, dass es im Browser unterschiedlich ist.

Falk Hoppe: Es ist eine Komfort-Library, ja.

Roman Stranghöner: Es sorgt sogar dafür, dass es Fallbacks für IE und sowas automatisch mit einbaut. Also die wissen in der Regel…

Stefan Tilkov: Wenn man sich darum nicht kümmern muss, ist alles gut.

Roman Stranghöner: Und man kann das sogar noch konfigurieren, also man kann sagen: “Ein IE und sonst was ist mir eigentlich egal.”, dann schaltet man das einfach weg und dann kriegt man im Prinzip den Support dafür nicht. Also da würden sogar die Mixins anfangen nur das rauszuliefern, was wirklich für die Browser, die ich unterstützen will, quasi. Also man würde da nicht mehr Zeug raus hauen, als man eigentlich müsste. Das ist ganz cool.

Falk Hoppe: Es hat mittlerweile aber halt eben auch Anteile wie, “Vertical Rhythm” und so sind z.B. solche Dinge, die ja für die Typographie relativ interessant sind. Und da kommt Compass halt auch mit Support um die Ecke und ähnliche Spielereien. Also es ist unglaublich mächtig.

Stefan Tilkov: Also das, was ich sonst vielleicht eher in einem Satz-System erwarten würde, in meinem Express oder so oder InDesign, das macht dann auf einmal der Präprozessor.

Roman Stranghöner: Was man vielleicht noch erwähnen sollte, da du gerade schon JQuery angesprochen hast, es ist nicht so, dass Compass so ein schwergewichtiges Framework ist, was ich einbinde und dann habe ich das irgendwie am Bein. Also auch Filesize-technisch, sondern ich importiere das im Prinzip in meinem .sass oder .scss und es werden wirklich nur die Dinge in meinem Kompilat landen, die ich tatsächlich benutze. Nicht auto-magisch irgendwie alles, was Compass mitbringt.

Falk Hoppe: Das ist extrem wichtig. Also gerade für Mobilgeräte halt extrem wichtig natürlich, nachher.

Stefan Tilkov: Ok, verstehe. Was gibt es noch an Frameworks? Also Compass war das eine, was du genannt hast. Was haben wir noch?

Falk Hoppe: Also der Punkt ist halt, dass man gerade durch diese Präprozessoren eigentlich mal ordentliche Grids verwenden kann. Also Grids…

Stefan Tilkov: Ah, moment. Stop, stop, stop. Schritt zurück. Was ist ein Grid? Was ist damit jetzt gemeint?

Falk Hoppe: Ein Grid ist eigentlich, kommt eigentlich aus dieser ganzen Print-Medien Geschichte, dass ich halt möchte, dass meine Komponenten möglichst über die ganze Seite verteilt das gleiche, die gleiche horizontale Aufteilung haben. Also ich möchte nicht, dass meine Überschrift irgendwie fünf Pixel links von meinem Blog-Text steht und drei Zeilen tiefer fängt der Text, fängt die Überschrift dann aber acht Pixel weiter links an. Also ich möchte immer relativ klare Linien haben und dabei hilft einem so ein Design- Grid. Also es werden Linien, vertikale Linien sozusagen, über die Webseite gelegt und an denen orientiere ich mich beim Aufbau meiner Komponenten.

Stefan Tilkov: Das ist ja eigentlich was Gutes. Also man könnte – erster Reflex wäre vielleicht zu sagen: “Das ist irgendwie ganz komisch, dass Web ist so dynamisch.” Aber diese Grids können ja auch dynamisch sein, können sich anpassen, was da in diesen View-Ports gerade reinpasst und tun das auch.

Roman Stranghöner: Die meisten sind auch responsive. Also selbst sowas wie Twitter Bootstrap und Konsorten, die haben auch sehr viele responsive Anteile, die sorgen schon automatisch dafür, dass wenn man die richtigen Klassen daraus benutzt, dass dann auch meine Komponenten sich vernünftig verhalten, wenn die Viewports kleiner werden.

Stefan Tilkov: Also wenn ein Grid eigentlich was Gutes ist, was für eine Rolle oder was ist daran schlecht? Weil darauf läuft es ein bisschen hinaus, glaube ich – ne, was du sagen willst.

Falk Hoppe: Also bei so einem klassischen Grid – ich war früher mal so ein extremer Gegner davon, weil so ein Grid nimmt einem ja nur ein bisschen Rechnerei ab. Es nimmt einem die Rechnerei ab, wie breit sollen meine Komponenten in welchem Container werden? Und man hat jetzt lange dafür gesorgt, dass ich das Frontend mit CSS von meiner Markup-Struktur abkapsel. Und das klassische Grid kam dann früher um die Ecke und hat dann sowas dran gepinnt, wie Klassen von “col1” bis “col9”, um die Breite meiner HTML- Komponente auszudrücken. Und das ist halt natürlich irgendwie fast nichts anderes als ein Style-Tag sozusagen an das Element zu schreiben, wo ich dran schreibe “Weite: 246px”.

Stefan Tilkov: Passt so ein bisschen zu den CSS-Klassen, wie “light blue”.

Falk Hoppe: Jaa, genau. Das ist einfach, ne, es ist keine semantische Klasse. Es ist einfach eine wirkliche Styling-Klasse, die überhaupt nichts mit der Komponente zu tun hat, die ich da in der Struktur darstelle.

Stefan Tilkov: Ich denke, man könnte das diskutieren. Also ich weiß nicht, ob ein Typograph das auch so sehen würde und nicht sagen würde: “Das Grid ist eine semantische Information.” Also, weißt du wie ich das meine? Also es ist natürlich, es ist dadurch, dass es da ist – aber ich verstehe, was du sagen willst. Was du sagen würdest, du hättest gerne – was hättest du gerne für eine Klasse?

Falk Hoppe: Ich fang anders an. Das kann man so sehen, aber jetzt gerade in so Responsivness kommt es natürlich darauf hin, dass sich auf einmal in einem anderen Media-Query ein “col6”-Element sich verhalten soll wie ein “col3”-Element.

Stefan Tilkov: Verstehe, ja ok. Das ist ein gutes Argument. Responsiv passt es dann definitiv nicht mehr. Auf einer Seite könnte man es vielleicht noch sagen, aber da.

Falk Hoppe: Es gibt irgendwie Vergewaltigungen davon, indem dann halt irgendwie dann das “col6”-Element nur noch so breit ist wie ein “col3”-Element, aber das ist natürlich irgendwie eher fuchtbar. Und so ein Precompiler-Framework kommt da natürlich sehr sehr gelegen, indem es mir erlaubt, solche Breitendefinitionen in Mixins oder ähnliches zu verpacken oder in Extend-Klassen und ich die in semantische CSS-Klassen reinladen kann.

Roman Stranghöner: Also die Media-Queries vor allem, die da drin stecken.

Falk Hoppe: Ja, Media-Queries sind nochmal dann der Topf oben drauf, aber ich kann halt erstmal hingehen und sagen: Meine Sidebar included irgendwie das “col3”-Mixin und im ganzen HTML steht nicht ein Mal “col3”. D.h., auch später – wenn ich bei einer normalen Grid-Webseite so etwas gehabt habe wie, ich habe eine Sidebar, die “col3” hat und ich habe noch irgendein Teaser- Element oder ähnliches, das “col3” hat und 5000 andere Elemente über meine Webseite und ich möchte jetzt aber, dass die Sidebar jetzt auf einmal breiter wird als dieser Teaser, dann muss ich durch mein Markup tigern und Klassen austauschen. Beim CSS hab ich jetzt den Vorteil: ah ok, meine Sidebar soll jetzt auf einmal breiter oder schmaler werden, dann tausche ich der halt da einfach nur das include. Und das Markup bleibt so, wie es ist. Und das finde ich sehr sehr charmant. Also das ist eigentlich auch meiner Meinung nach der einzige Weg, wie man das machen sollte. Also quasi semantisches Grid ins CSS zu legen.

Stefan Tilkov: Also in meinem HTML wären dann semantische Aussagen, semantische Klassen, wie z.B. “secondary” oder “navigation” oder “teaser”, was genau du da als Beispiele genannt hast, ok. Aber ich könnte theoretisch das gleiche auch erreichen, indem ich nicht das HTML als Quelle betrachte, sondern indem ich die Vorstufe zu dem HTML als Quelle betrachte, die Template oder was auch immer, woraus ihr das HTML erzeugt. Ist das nicht genau die gleiche Aussage eigentlich?

Falk Hoppe: Wo du halt nicht dran vorbei kommst ist, dass du ja das Styling aber mit dem CSS machst. D.h., du kannst da sehr schlecht die Brücke schlagen. Also du musst trotzdem halt dann wieder eigene Klassen – also du hast entweder diese Klassengruppen, die du halt hast, die du dann ins CSS transferieren musst oder also zumindest kommt es in der Änderung nicht zurück.

Stefan Tilkov: Also bei diesem Ansatz, wenn ich es in der Vorstufe zum HTML machen würde, würde ich mir praktisch eine zweite eigene Design-Sprache definieren, in der ich das machen würde. Ok, so kann ich eben CSS bzw. in der, genau genommen eben nicht in der CSS, sondern in der “sass”- oder “scss”-Welt bleiben und da über die Mixins auslagern, sozusagen modularisieren, Seperation of Concerns betreiben und habe an genau eine Stelle die Definition, dass ein Teaser bei mir “col3” ist oder was auch immer das ist, ok.

Falk Hoppe: Genau.

Roman Stranghöner: Und da spielen dann z.B. bei diesem Architekturkonzept SmaCSS z.B. diese Layout-Dinger rein. Also ein Layout für eine Artikelseite beispielsweise legt dann fest, wie im Prinzip meine Komponenten in dieses Grid gepresst werden. Also die Informationen darüber, wie breit irgendwas ist, liegt nicht in meinem Modul oder in meiner Komponente, sondern die steht im Prinzip in diesen Layout-Styles, die festlegen wie diese Modula auszusehen haben auf meiner Landing-Page, auf meiner Artikel-Page oder auf meiner “was weiß ich was Seite”.

Falk Hoppe: Das ist halt auch so ein bisschen das schöne – ich weiß gar nicht mehr das Stichwort was SOLID ist – aber es gibt halt dieses Prinzip auch, dass ich einer beliebigen Komponente in eine beliebige Parent- Komponente werfen können sollte, ohne dass die Parent-Komponente bricht.

Stefan Tilkov: “liskov substitution principle”

Falk Hoppe: Genau, ja ja. Ne, dass ich halt mir darüber keine Gedanken machen muss bzw. die Komponente oben drüber sollte nicht wissen, was in sie rein geworfen wird. Das ist mit solchen Grids da sehr schön einfach.

Stefan Tilkov: Gut, also ihr seid voll dafür, da sowas zu benutzen. Also ein Grid zu benutzen, wenn man einen Präprozessor hat. Bei Präprozessoren würdet ihr klar auf Sass setzen. Wird sowas wie Bootstrap eigentlich mit Less oder mit Sass gemacht?

Roman Stranghöner: Less. Bootstrap ist Less und Foundation – das ist so der große Klon.

Stefan Tilkov: Haben wir neulich glaube ich benutzt. Kann mich noch erinnern.

Roman Stranghöner: Genau und das ist in Sass geschrieben. Und die machen sich halt genau sowas zu nutze. Also ich glaube wenn man – auf der Bootstrap-Seite kann man das Ding auch komplett Customizen und das klappt halt nur, weil die halt für alles mögliche Variablen benutzen und dann kann man sich das ganz schnell on-the-fly…

Falk Hoppe: Wobei es jetzt nicht dagegen spricht. Also man könnte jetzt rein theoretisch sogar ein Bootstrap nehmen und on-the-top quasi das eigene CSS dann mit Sass schreiben. Das ist eigentlich kein – also das ist jetzt vielleicht nicht die schönste Variante.

Stefan Tilkov: Ah ok. D.h., man kann das auch mischen. Man könnte sozusagen statisches CSS; aber dann hat man die Parameter; oder man müsste die Parameter ersetzen.

Falk Hoppe: Genau, man kann halt eben nicht mehr das Vendor-CSS, was man quasi sich einkauft, kann man natürlich nicht mehr als Mixins benutzen.

Roman Stranghöner: Also um so ein paar Grids nochmal zu nennen in der Sass- Welt, von denen wir jetzt so schwärmen, das wäre z.B. Susy, ist eins von diesen responsive, semantischen responsive Grids.

Falk Hoppe: Und heute ganz…

Roman Stranghöner: Singularity.

Falk Hoppe: Ja, das ist super.

Roman Stranghöner: Das sind im Prinzip so reine Sass-Libraries. Das kommt gar nicht quasi als generiertes Ding irgendwie, so wie Bootstrap daher, was ich nur noch einbaue, sondern da benutze ich wirklich nur noch das Framework als – genau also die Mixins von diesem Framework. Also ähnlich, wie ich Compass benutze, heißt das nicht nur, wenn ich Susy benutze, dass ich dann wieder irgendwie zusätzlichen Code einbinde, der dann auch auf meine eigenen Dateien – ich habe den Faden verloren. Genau, also es wird nur das includiert, was ich tatsächlich benutze.

Falk Hoppe: Und das ist auch sehr sehr konfortabel. Das sind halt wirklich dann im Prinzip Einzeiler, um solche Grids einzubetten. Das ist wirklich sehr sehr konfortabel.

Stefan Tilkov: Also ich sehe schon wieder längliche Shownotes auf uns zukommen. Gut ok. Lasst uns Schluss machen, um es nicht zu lang werden zu lassen. Habt ihr noch ein abschließendes Statement, berühmte letzte Worte zu Präprozessor?

Falk Hoppe: Also ich wäre mal wieder, also wie gesagt ich habe es grad schon mal erwähnt: meiner Meinung nach sollte man kein Projekt mehr ohne machen. Also und wenn man Less benutzt. Ich bin jetzt auch nicht gegen Less. Ich finde die Arbeit wird mit Less auch toll. Aber man sollte auf jeden Fall einen Präprozessor benutzen.

Roman Stranghöner: Genau.

Falk Hoppe: Auch als Anfänger. Also gerade weil man eben – man muss die Sachen nicht nutzen, aber man kann die Sachen nutzen und man lernt sukzessive dadurch.

Stefan Tilkov: Alles klar.

Roman Stranghöner: Der nette Einstieg ist eigentlich mit “scss” anzufangen, weil man da halt das bestehende Wissen von CSS direkt quasi nehmen kann und dann fängt man mit einfachen Dingen an, wie Variablen ersetzen.

Falk Hoppe: Das ist bei Less aber genauso. Also Less, “scss” – das wären so die Kandidaten.

Roman Stranghöner: Genau.

Stefan Tilkov: Gut, vielen Dank an euch beide. Danke an die Zuhörer, bis zum nächsten Mal.

Falk Hoppe: Bis dann.

Roman Stranghöner: Ciao.