© saicle/Shutterstock.com
Die Build-Automatisierungstools im Vergleich

Grunt vs. gulp


Wollten JavaScript-Entwickler in der Vergangenheit Codeverarbeitungsaufgaben automatisch ausführen, so mussten sie sich meist bei den Nachbarn der Java- und Ruby-Entwickler bedienen. Ant, Maven oder Rake samt einer Horde Plug-ins wurden zu einem sehr eigenen Öko­system zurechtgebogen. Meist mehr schlecht als recht und mit einem nicht unerheblichen Wartungsaufwand verbunden. Doch das geht auch deutlich einfacher.

Denn seit einiger Zeit sind Node.js-basierte Automatisierungstools nicht nur voll im Trend, sondern auch als das Schweizer Allzweckmesser für Frontend-Entwickler nicht mehr aus unserem täglichen Workflow wegzudenken. Wir nehmen mit Grunt und gulp die populärsten Vertreter der Gattung Kehllaute unter die Lupe und sehen uns an, ob man im Problemfall eher grunzen oder würgen sollte.

Kleine Grunt-Geschichtsstunde

Es war einmal ein Cowboy mit dem Namen Ben Alman, ein bekannter Star der jQuery-Community. Er hatte die löbliche Angewohnheit, seinen JavaScript-Projekten mit automatisierten Qualitätssicherungs- und Nachverarbeitungsprogrammen den letzten Feinschliff zu verpassen: JavaScript-Code wurde gelintet, kopiert, konkateniert und schlussendlich mit Closure-Compiler oder Ähnlichem in ein minimalisiertes und sauberes Endprodukt gepackt. Um das halbwegs effizient durchzuführen, bediente er sich bei den benachbarten Programmiersprachen und verwendete so genannte Build-Tools, um die Aufgaben in eine entsprechende, voll automatische Abfolge zu bringen.

Zum Beispiel mit dem HTML 5 Boilerplate Ant Build Script [1]. Mit dem über 1 500 Zeilen langem XML-File ist es zwar möglich, all die oben genannten Tasks durchzuführen – allerdings merkt man an der Anzahl der verwendeten Plug-ins und der umständlichen bis gar nicht vorhandenen Konfigurationsoptionen, wie mühselig sich das gestalten kann. Auch ein guter Indikator: Vom eigentlichen Stammtasksortiment von Ant mit über 150 Tasks werden in diesem Build-File nur vier tatsächlich genutzt. Der Rest ist Zusatz.

Alternativen zu den fremden Build-Welten waren grafische Tools wie CodeKit [2], die sich allerdings auf diverse Betriebssysteme beschränkten und in Sachen Continuous Integration/Deployment so gut wie unbrauchbar waren.

Kein Wunder also, dass Ben Alman einen entsprechenden Grant (süddeutsch für: Unmut – und das ist noch lieb ausgedrückt) hatte, als er auf der Suche nach dem brauchbarsten Tool für Frontend-Tasks letzten Endes zum Entschluss kam, sein eigenes zu schreiben und mit einem zornigen Warzenschwein zu ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang