brainbits Blog

Die Geschichte von node-sass – oder wie wir unsere Projekte wartbar machten

Antonia Ilski24.02.2016Frontend • Anwendungsentwicklung • Code
Sass-Logo

Seit einigen Jahren ist Sass als Preprozessor für CSS aus der täglichen Frontend-Entwicklung nicht mehr wegzudenken. Auch brainbits setzt in den Webprojekten seit Jahren auf Sass. Die Gründe sind mannigfaltig und einleuchtend:

  • Der Code ist aufgeräumt und lesbar
  • Durch den Einsatz von Variablen und Mixins wird duplicate code vermieden

Als konkretes Produkt haben wir uns anfänglich für Compass entschieden, da es eine große Bibliothek von Mixins und Helferlein bereitstellt. Dabei wurden allerdings komplexe Aufgaben immer mehr zum Problem. Je größer ein Projekt, umso länger benötigte Compass, um die CSS-Dateien zu erstellen. Bis zu 30 Sekunden konnte es dauern, bis alle nötigen CSS-Dateien kompiliert waren. An eine flüssige Entwicklung war nicht mehr zu denken.

Da Sass und Compass im System des Entwicklers installiert sind, konnten wir auch in neuen Projekten nicht immer die neuen Versionen der Tools verwenden, da das unter Umständen die älteren Projekte beeinträchtigt hätte.

Wie node-sass alle Probleme löste

Wir brauchten also eine neue Lösung für den projektspezifischen Sass-Einsatz, unabhängig vom Entwicklungssystem. Unser brainbits-Team Adler hatte im Vorfeld für die Dokumentation von Code mit Node.js einen Webserver aufgebaut, der bei jedem Request CSS-Dateien aus Sass generierte und das Ergebnis anzeigte.  Und das ging schnell. Node.js war damit die Lösung für mindestens eines unserer Probleme.

Kurz darauf begannen wir ein neues Projekt und wagten uns an Node.js und Grunt zum Erstellen unserer Sass-Dateien. Nun konnten wir unsere Tools endlich ganz spezifisch für die Projekte auswählen und verwenden. Über diverse Grunt-Plugins hatten wir nun auch die Performance unserer Seiten voll im Griff. Die ausgelieferten Dateien im Produktivmodus wurden zusammengefasst und auch Entwicklerkommentare wurden entfernt. So gelang es uns, mit Node und node-sass eine perfekte Arbeitsumgebung für unsere Projekte zu schaffen.

Oder auch nicht?

Was jedem beim Umstieg von Ruby Sass auf node-sass klar sein muss: Nicht immer steht einem bei Versionsupdates der volle Funktionsumfang von Sass zur Verfügung. Die neuen Funktionen müssen dabei erst in libSass integriert werden, bevor node-sass sie verwenden kann.

Anfangs installierten wir deshalb mit Bower alle Pakete, die das Web-Projekt brauchte: JavaScript-Bibliotheken und natürlich Compass. Doch Compass kam nicht im gewohnten Umfang, wir konnten nur die Mixins verwenden. Sprites und Funktionen wie {headings} blieben uns ohne Ruby Compass verwehrt. Dennoch belastete das Compass-Package unsere Projekte mit zusätzlichen 520KB an Daten. War das wirklich notwendig? Wir stellten unsere Arbeitsweise erneut auf den Prüfstand. Wofür benötigen wir Compass und wie können wir die fehlenden Funktionen ablösen?

Für Sprites hatten wir mit grunt-imagine eine Lösung gefunden, mit der sich gute Ergebnisse erzielen lassen. Und auch die wenigen Funktionen, die wir von Compass lieben gelernt haben, können wir selbst erstellen. Blieb also ‚nur’ noch das Problem mit den Prefixen für CSS3 – doch auch dafür gab es bereits eine Lösung: grunt-postcss

grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),        
    sass: {
        options: {
            includePaths: [
                "bower_components/susy/sass",
                "bower_components/magnific-popup/src/css/"
            ],
            require: 'susy'
        },
        dev: {
            options: {
                sourceMap: true,
                outputStyle: 'nested'
            },
            files: sassFiles
        },
        release: {
            options: {
                sourceMap: false,
                outputStyle: 'compressed'
            },
            files: sassFiles
        }
    },
    postcss: {
        options: {
            map: false,
            processors: [
                require('autoprefixer')({browsers: 'last 3 versions'
            ]
        },
        dist: {
            src: 'web/styles/**/*.css'
        }
    }
});

grunt.loadNpmTasks('grunt-sass');
grunt.loadNpmTasks('grunt-postcss');

// Default task(s).
grunt.registerTask('default', ['concat:dev', 'sass:dev']);
grunt.registerTask('build-release', ['sass:release', 'postcss', 'concat:release']);

Deshalb entschieden wir uns gegen den weiteren Einsatz von Compass und nutzen seitdem die genannten Grunt-Plugins.

Nach einem Jahr ohne Compass können wir rückblickend sagen: Compass hat seine Daseinsberechtigung. Es bietet viele Mixins und Funktionen, die die Arbeit des Frontend-Entwicklers erleichtern. Wenn man jedoch nur einen Bruchteil davon wirklich nutzt, sollte man prüfen, ob andere, weniger umfangreiche Tools ausreichend sind.

Zurück zur Übersicht