Grunz! Attack of the Shopware Warthog! grunt.js mit Shopware im Praxistest

grunt.js
Leise und unbemerkt erschien auf der Seite der Shopware AG ein Tutorial. Und zwar für ein Bündel von neuen Technologien, die bald in Shopware genutzt werden und das Frontend-Development drastisch verändern dürften. Scaffolding mit grunt.js. Bereits auf dem Shopware Community Day wurde grunt.js angekündigt und dazu ein neues Scaffolding-System – also von Grund auf Templates bauen.

Und ich erhoffe mir davon, dass einiges einfacher wird. Denn das Grunddilemma, vor dem jeder Frontend-Entwickler steht, lautet: soll das bestehende Template als Child Template abgeleitet werden oder lohnt es sich von Null auf ein eigenes Template zu Schreiben?

Was bei WordPress theoretisch noch denkbar ist (und schon da eigentlich keine Option ist), ist bei einem Shopprojekt Shopware viel zu aufwendig. Es wurde dort schon jede Menge Arbeit in HTML, CSS und Javascript gesteckt und das lässt sich nicht „mal eben“ von scratch auf besser gestalten. Der Nachteil: Tools wie HTML5 Boilerplate oder Frameworks wie Bootstrap scheiden dadurch aus. Und auch in der täglichen Arbeit gibt es Nachteile: es sammeln sich durch Plugins und Templatevererbungen jede Menge CSS-Files an, die alle getrennt eingebunden werden. So schön Pluginsystem und Templatevererbungen sind: in der Regel schreibt jede Instanz ihr eigenes Template-File in den Code. Und das von Hand zu warten ist nahezu unmöglich, zumal ich dann nicht ohne weiteres Updates einspielen oder neue Plugins installieren kann.
Die Files liegen alle einzeln vor und sind nicht minifiziert. Dasselbe gilt für Javascript-Dateien. Dafür gibt es inzwischen automatisierte Lösungen und hier setzt die Lösung mit grunt.js ein: automatisierte Tasks werden von grunt.js, dass über den node.js läuft, übernommen. Ich lege ein Konfigurationsfile in Javascript-Syntax an (das ist ähnlich wie bei Puppet) und definiere dort die Tasks, die durch die geladenen Module ausgeführt werden sollen.

Etwa die Kompilierung von LESS und SASS Files. Das System ist erweiterbar durch contributions, die auch alle auf github zur Verfügung stehen. Damit wäre alles dazu schon gesagt und zur Installation und Basiskonfiguration gibt es auch bereits etliche Tutorials.

Weniger zum Einsatz in der Praxis. Hierzu habe ich ein Testsystem aufgesetzt – und dabei funktioniert alles soweit wie gewünscht. Wie wäre es denn, wenn ich mir auch aus den default und _emotion Templates bestimmte CSS-Files minifizieren lasse? Wenn IE-Files via Browserweiche eingebunden werden, sollten diese nicht übernommen werden, genausowenig CSS Files für Print. Ja, das geht. Das wäre sogar ein konkreter Anwendungsfall, der bereits existiert.
Schließlich möchte ich nicht bei jedem Update alle Files nochmal neu heraussuchen und per Hand minifizieruen und zusammenfügen. Richtig praktisch wird es dann, wenn eben SASS oder LESS eingesetzt wird. Ich kann mir dann auf Knopfdruck oder auch automatisiert durch die fertigen Templatefiles kompilieren lassen. Zumal sich der Nutzen erst richtig erschließen wird, wenn Shopware die neue Template-Basis enthüllt (was auch dem Community Day für Version 4.3 angekündigt wurde, wenn ich mich recht entsinne). Wenn dann das unkompilierte LESS-File zur Verfügung steht habe ich eine Basis, von der ich von Grund auf ein Template ohne die typischen Redundanzen von CSS mit mehreren Stylesheets erstellen kann.
Und vielleicht sehen dann Shopware Shops auch individueller aus mit nicht immer genau denselben jQuery-Animationen und Imageslidern.
Praktisch auch die Sache, Grunt-Definitionen für Development und Produktiveinsatz zu definieren. Schließlich benötige ich beim Bearbeiten von CSS Files die unkomprimierte Version im Browser, um dort mit Webkonsolen und den entsprechenden Zeilenangaben etwas anfangen zu können.
Wie sich das Ganze dann wirklich in der Praxis verhält – darauf bin ich gespannt. Die Files inklusive dem Gruntfile.js müssten am besten ja mit auf dem Server liegen. Ansonsten gibt es ein klassisches Szenario: die Agentur oder der Dienstleister für die Shopware-Betreuung wechselt und der neue Dienstleister findet nur bis zur Unkenntlichkeit berarbeitet Files vor, die quasi nicht mehr zur Bearbeitung genutzt werden können.

Fazit: Es steht im Frontend-Bereich derzeit generell einiges an. Der Abkehr von starren Raster-Layouts ist eingeleitet und unter dem Stichwort „Responsive“ kommen fluide Layoutraster zum Einsatz, die sehr viel aufwendiger zu gestalten sind als die bisherigen Layouts. Dafür wird man neue Technologien einsetzen müssen, um effektiv arbeiten zu können. grunt.js ist hier nur ein Baustein, wohin die Reise geht wurde ja von Stephan Pohl schon auf dem SCD2013 beschrieben, siehe die Slides. Ja, ich sehe den Sinn darin und werde grunt sicherlich nutzen.

Eine Antwort zu “Grunz! Attack of the Shopware Warthog! grunt.js mit Shopware im Praxistest”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.