Pro vs. Cons Sass (Syntactically Awesome Stylesheets)

[Kay]

Hallo,

Wer hat Erfahrung mit Sass (Syntactically Awesome Stylesheets)?

Was spricht dafür und was dagegen es einzusetzen?

Kay

[molily]

Wir setzen nur noch Haml und Sass (sowie verstärkt CoffeeScript) ein. Die meisten unser Projekte sind aber auch in Ruby on Rails. Da ist es sehr einfach, Sass zu integrieren. Wir schreiben hauptsächlich den .sass-Dialekt (nicht .scss). Schreibt man .scss, dann muss man seine gewohnte Syntax nur wenig abändern.

Über die Imports lassen sich Stylesheets sehr gut modularisieren, ohne dass man sich über das Kompilieren Gedanken machen muss. Das nimmt einem Sass ab. Imports unterscheiden zwischen echten Imports und solchen, die von Sass aufgelöst werden, was sehr sinnvoll ist.

Mixins, Variablen und einfache mathematische Operationen sind ebenfalls äußerst brauchbar. Clearfix ist ein häufiger Mixin, sämtliche Farbwerte sollten Variablen sein und Berechnungen braucht man oft, wenn man nicht mit box-sizing das ganze Box-Modell ändern will.

Was mir eher ein Dorn im Auge ist, ist die Verschachtelung von Regeln. Das ist jetzt kein Nachteil an sich, aber es verführt dazu, das CSS genauso in einem »Baum« zu schreiben wie das DOM:

<section>
  <h1>foo</h1>
  <article>
    <p>
      <a href="">

Sass legt einem nahe, sein Stylesheet analog aufzubauen:

section
  h1
    font-size: 150%
  article
    border: 1px solid red
    p
      margin: 1em 0
      a
        color: red

Das hat schon seine Logik, führt allerdings zu unnötig langen Selektorketten (section article p a { color: red }), wo beispielsweise »article a« ausreichen würde. Hier sollte man Sass-Code immer möglichst »links halten«, kleine autonome Pakete schreiben und Verschachtelung nur nutzen, wenn es zum Selektor etwas sinnvolles beiträgt.

Mathias

[Kay]

Hallo Mathias,

danke für den Typ mit CoffeeScript. Werde mir das mal ansehen.

Ich nutze fast nur noch Python, um habe es bisher nicht bereut. In PyPI findet man fast immer eine oder mehrere Lösungen zu einem Problem.

Kay

[entropie]

Hi

Das hat schon seine Logik, führt allerdings zu unnötig langen Selektorketten (section article p a { color: red }), wo beispielsweise »article a« ausreichen würde. Hier sollte man Sass-Code immer möglichst »links halten«, kleine autonome Pakete schreiben und Verschachtelung nur nutzen, wenn es zum Selektor etwas sinnvolles beiträgt.

Hm, versteh ich nicht? Wenn dir die selektor ketten zu lang sind kürze sie halt einfach? Es zwingt dich ja keiner den kompletten DOM tree im sass abzubilden.

Ich halt das aber auch für kein problem. Das css file wird nur einmal geladen und sollte dann cached werden. Die paar bytes mehr machen mir da nichts.

Zum Thema allg:

Ich bin ein grosser Sass/Haml fan. Obwohl ich sagen muss das ich wegen der performance überlege mir eine alternative für Haml zu suchen. Es ist einfach *verdammt* Langsam. Ich werde slim mal probieren/benchmarken, mal sehen ob es da sichtbare unterschiede gibt.
Bei sass werde ich jedenfalls bleiben.

[molily]

Wenn dir die selektor ketten zu lang sind kürze sie halt einfach? Es zwingt dich ja keiner den kompletten DOM tree im sass abzubilden.

Das ist mir schon klar, ich schrieb ja auch, dass man das nicht muss, sondern nur, dass viele offenbar durch Sass dazu verleitet werden.

Ich halt das aber auch für kein problem. Das css file wird nur einmal geladen und sollte dann cached werden. Die paar bytes mehr machen mir da nichts.

Es ging mir nicht um die Dateigröße, sondern die Komplexität von zahlreichen descendant selectors.

Obwohl ich sagen muss das ich wegen der performance überlege mir eine alternative für Haml zu suchen. Es ist einfach *verdammt* Langsam.

Dafür gibt es das Caching von Templates als statische HTML-Dateien, oder?

Mathias

[entropie]

Hi

Wenn dir die selektor ketten zu lang sind kürze sie halt einfach? Es zwingt dich ja keiner den kompletten DOM tree im sass abzubilden.

Das ist mir schon klar, ich schrieb ja auch, dass man das nicht muss, sondern nur, dass viele offenbar durch Sass dazu verleitet werden.

Das ist sicher auch eine frage der Komplexität des projekts. Im prinzip kann ich keine nachteile an langen selektor ketten erkennen - im gegenteil.

Ich halt das aber auch für kein problem. Das css file wird nur einmal geladen und sollte dann cached werden. Die paar bytes mehr machen mir da nichts.

Es ging mir nicht um die Dateigröße, sondern die Komplexität von zahlreichen descendant selectors.

Ich glaub das ist kein problem von SASS. Das ist ein allgemeines CSS problem. Durch mixins kann man in SASS da noch wesentlich besser entgegenwirken. Aber irgendwann fliegt einem das um die ohren wenn man nicht permanent refractored und anpasst.

Obwohl ich sagen muss das ich wegen der performance überlege mir eine alternative für Haml zu suchen. Es ist einfach *verdammt* Langsam.

Dafür gibt es das Caching von Templates als statische HTML-Dateien, oder?

Ja. Aber wenn ich mich an das benchmark (kam glaube vom Ramaze projekt erinner - das Ruby MVC framework meiner wahl - ist der geschwindikeitsunterschied ENORM. Das 2 langsamste war irgendwie mit 2 sekunden knapp 10 sekunden schneller als Haml.

Noch benuzt ich in jedem Projekt haml, und ich mag ich es mittlerweile ziemlich. Trotzdem ist es nervig immer die performance probleme im hinterkopf zu haben. Caching hin-oder-her, einmal muss es geparst werden.

Mathias

Mfg entropie