Frontend Entwicklung aufgebohrt – Alles unter Kontrolle mit dem richtigen Toolset

Taskrunner, wie z.B. Gulp oder Grunt, sind sicher vielen ein Begriff. Wer sich eingehend mit ihnen beschäftigt hat und sie erfolgreich in seine Arbeitsroutinen eingebunden hat, will sie auch nicht mehr missen. Mir geht es genauso.

Wenn es mal schnell gehen soll… und das soll es immer, geht es eigentlich nicht mehr ohne. Mal eben ein paar Scripte linten, ein bisschen SASS prefixen, den Quellcode mal eben auf links drehen und wieder zurück, Scripte bundeln, Quellcode, Scripte und Styles minimieren und als seperate DEV-Version für’s Team und als DIST-Version auf den Server… warum nicht, geht ja. Wenn das ganze dann noch von der „Hauseigennen“ Versionierung mit GIT begleitet wird ist alles halb so wild.

Nun ist es aber so, dass die Welt sich weiter dreht. Und das ist gut so. Täte sie es nicht, würden wir alle ziemlich dumm aus der Wäsche gucken und hätten ernst zu nehmende Probleme mit den Füssen auf dem Boden zu bleiben… das aber nur am Rande.

Während all der Rotationen ist einiges passiert, in Sachen „Für’s Web entwickeln“ und ein weiterer, kontrovers diskutierter, Kandidat bereichert nun die Szene. Webpack ward geboren.

Webpack? WTF is Webpack?

Zu erst einmal… Webpack ist KEIN Taskrunner! Webpack ist ein Bundler!

Wer mit „seinem“ Taskrunner glücklich ist, macht ganz sicher nichts falsch dabei zu bleiben. Trotzdem lohnt sich der Blick über den Tellerrand.

Webpack verfolgt einen anderen Ansatz als ein Taskrunner. Während ein Taskrunner definierte Aktionen abarbeitet und als Resultat einen Schwung Dateien ausgibt, sammelt Webpack alle Module und Abhängigkeiten und generiert ein statische Assets (ein Bündel) daraus. Wie man dieses Bündel schnürt lässt sich haarfein deklarieren und es wird minimiert und ge-prefixt etc. was das Zeug hält. Genauso wie bei jedem Taskrunner, der etwas von sich hält, gibt es auch für Webpack eine große Anzahl Plugins und Loader mit denen sich so gut wie jedes Zipperlein behandeln lässt. Was Webpack nach dem Bundeln, dann präsentiert kann sich sehen lassen. Besonders in Punkto Performance (sowohl während der Verarbeitung als auch auf dem Server) macht Webpack Sinn.

Allerdings hat Webpack auch seine Schattenseiten. Die Konfiguration ist nichts für schwache Nerven oder ungeduldige Zeitgenossen… man muss wirklich Biss haben um das ganze sauber zum laufen zu bringen.

Also doch lieber bei Gulp bleiben und Webpack ignorieren?

Gulp ist mein Gewinner wenn es um die Einfachheit geht. Er läuft. Wenn es darum geht nur einen Teil eines Projekts zu bearbeiten bleibt er meine erste Wahl. Mit Gulp oder Webpack lässt sich so gut wie jeder Workflow wunderbar handeln. Gulp ist aber viel einfach in der Usability. Webpack hingegen ist erheblich flexibler und die Entwicklung ist schneller. Unterm Strich entscheidet der eigene Stil und die persönlichen Vorlieben.

Beide Lager haben ganz klar ihre Berechtigung. Kommt man von Gulp hat man schnell das Gefühl Webpack ist etwas zu viel des Guten und wünscht sich etwas mehr von der „Gulpischen“ Einfachheit. Ist man bei Webpack gelandet, faszinieren einen die Vielzahl der Möglichkeiten. Die Kombination aus beiden, Webpack und Gulp ist ein doppelter Gewinn und man liefert schnellere und bessere Webseiten ab!

Just my 2 cent’s

Ähnliche Artikel

Deine Meinung zu dem Beitrag!

Du hast zusätzliche Informationen, Anregungen und Ergänzungen zu diesem Thema oder einen Fehler gefunden? Dann lass es mich wissen, ich freue mich über einen Kommentar von dir. Wenn du diesen Beitrag als wichtig empfindest, kannst du ihn auch gerne weiterempfehlen. Jede Unterstützung ist willkommen.

Leave a Comment