Things I did.

Letzte Woche hatte ich Urlaub. Letzten Sonntag bin ich für drei Tage nach St. Peter-Ording (präziser: „Bad St. Peter“) gefahren, wo es mir vor zwei Jahren so gut gefallen hatte und was damals für meine „emotionale Hygiene“ so wichtig war. Diesmal bin ich nicht ganz so geflasht zurückgekommen.

  • Dieses Jahr lag der Urlaub ca. vier Wochen später. Diese vier Wochen zwischen Ende Oktober und Ende November machen bei den Läden/Restaurants vor Ort einen großen Unterschied. Viele Läden haben geschlossen oder ihre Öffnungszeiten verändert. Google Map is shit und die Websites der Geschäfte/Restaurants sind nur manchmal hilfreich.
  • Das Wetter war ein gelangweiltes Grau in Grau. So gut wie kein Wind – für Windstille bin ich eigentlich nicht an die Nordsee gefahren. So gut wie keine Sonne. Temperaturen im Niemandsland zwischen kalt und warm.
  • Drei Tage waren für Alltags-Detox zu wenig. Erst am dritten Tag fingen der Kopf an, den Alltag loszulassen – aber dann war auch schon Abfahrt. Mein Fehler.

Grundsätzlich bleibt aber die Landschaft geil – Spazierengehen durch die endlosen Weiten des Wattenmeers und Salzwiesen ohne eine Menschenseele zu treffen.

St. Peter Bad, Wattenmeer

Things I worked on.

Vor und nach dem Kurzurlaub hatte ich zwei Websites eines Kunden zu aktualisieren. Anlass war der Umzug des Geschäftssitzes. Für mich war das vor allem der Tritt in den Allerwertesten, endlich mit einem Vorhaben fortzufahren, was schon seit einem Jahr auf meiner To Do-Liste steht: das Umschwenken von (Kunden-)Websites weg von cloudbasierenden Webschriften von Typekit hin zu selbst gehosteten Schriften.

Typekit ist vor Jahren von Adobe übernommen worden. 2018 hat Adobe dann den Wechsel der Preisstruktur von Typekit weg, hin zu dem überteuerten Adobe Cloud-Rip-Off angekündigt, der für mich irgendwann 2020 in Kraft treten würde. Seit dem habe ich bei etlichen Schriftenbundles von „Design Cuts“ zugeschlagen, um ein Portfolio an Webfonts aufzubauen – nur für die Umstellung der Sites fand ich noch keine Zeit.

Die Umstellung der ersten Website nahm viel Zeit in Anspruch. Die Site ist 2004 entstanden und das Projekt wurde von mir fast auf den Tag genau, vor fünf Jahren, 2014, auf Grunt umgestellt – mit all den Problemen die es zB mit SCSS inzwischen macht. Grunt hat, ähnlich wie Gulp, inzwischen das Ende seiner Lebenszeit erreicht. Deswegen habe ich den Scope „Umstellung auf eigene Webfonts“ zu „Wechsel auf einen ’zukunftssicheren‘ (YMMV) Task-Runner“ aufgebohrt.

Als Frontend-Entwickler rauscht über Twitter und Newsletter immer eine gewisse Nachrichtenlage über angesagte Frontend-Dinge vorbei. Daraus entstand bei mir der Eindruck, dass WebPack in Sachen Task-Runner „state of the art“ sei und begann am Tag vor dem Urlaub, dieses mal anzutesten und Grunt raus- und Webpack rein zu schmeissen.

Am frühen Abend bekam ich dann die Kinnlade nicht mehr geschlossen – so erstaunt war ich über das Ergebnis, dass WebPack als Task Runner für Dinge jenseits eines JavaScript-Fokus im Grunde genommen nur ein notdürftiger Hack ist. Das für mich so offensichtliche Ergebnis, entsprach so gar nicht dem Bild, den viele Artikel im Frontend-Bereich vermitteln. Im Nachhinein erkläre ich es mir damit, dass viele Entwickler im Bereich der JS-Frameworks wie React, Vue, Angular & Co. mit WebPack einen Hammer bekommen haben und damit nur noch Nägel zum Reinschlagen sehen.

Meine Probleme mit der WebPack-Verwendung außerhalb der JS-Welt, zB für SCSS/CSS, Templating oder Assets-Verwaltung, erklären sich aus dem Aufbau von WebPack. Vereinfacht funktioniert WebPack so:

  1. WebPack arbeitet anhand einer selbst erstellten Konfigurationsdatei
  2. Dort werden Dateien werden als „Entrypoints“ eingetragen.
  3. Aus jeder als Entrypoint abgelegten Datei, extrahiert WebPack einen „Dependency Tree“ und holt sich alle weitere Dateien, die als „Abhängigkeit“ im Entrypoint verlinkt/importiert wurde. Diese Dateien werden in einem Workflow reingekippt. Je nach Dateinamen/-Endung/-Ort kann ein eigener Workflow aufgezogen werden.
  4. Der Workflow ist eine Abfolge von in der Konfiguration eingetragenen Modulen, die die reingekippten Dateien bearbeiten. Z.B. bei SCSS: mache aus SCSS-Inhalt einen CSS-Inhalt. Transformiere den CSS-Inhalt mit Autoprefixer.
  5. Das Endprodukt jedes Entrypoints ist eine JavaScript-Datei, die die Summe der durch den Workflow bearbeiteten, abhängigen Dateien enthält.

Die Betonung liegt auf: jede als Entrypoint abgelegte Datei produziert exakt eine Javascript-Datei. Ja, auch wenn ich eine SCSS-Datei als Entrypoint ablege und durch einen CSS-Workflow jage, ist das Endprodukt eine Javascript-Datei. Diese enthält CSS-Anweisungen, die in einem WebPack-Wrapper verpackt sind – wenig hilfreich.

Also muss am Ende des Workflows ein weiteres Modul eingehängt werden: MiniCssExtractor – der extrahiert aus der produzierten JS-Datei den CSS-Code und schreibt ihn in eine CSS-Datei.

Damit produziert WebPack also zwei Dateien: eine CSS-Datei und eine nutzlose JS-Datei. Um diese los zu werden, muss noch mal ein Modul am Ende des Workflows eingehängt werden, damit die nicht benötigte JS-Datei gelöscht wird – im Gegensatz zum MiniCssExtractor gibt es aber hier kein etabliertes Standard-Modul, sondern ein halbes Dutzend von irgendwelchen händisch zusammengeklöppelten WebPack-Modulen.

Genau diese Geschichte mit dem MiniCssExtractor und dem JS-File-Remove-Modul ist für mich die Quintessenz des WebPack-Missverständnisses. Es ist kein Task Runner, sondern ein JS-Module-Bundler. Fair enough, steht ja auch drauf. Aber das so viele das Ding als Task Runner vergewaltigen, hat mich schon verblüfft.

Selbst WebPack, 2012 gestartet, scheint das Task Runner-Thema erst jetzt auf den Schirm zu bekommen. Der MiniCssExtractor wurde im Mai 2019 Nachfolger des ExtractTextWebpack-Moduls, das im März 2018 durch Umstellungen in Webpack 4 gegen die Wand gefahren wurde. Das Problem mit der Produktion einer nicht benötigten JS-Datei soll irgendwann 2020 mit Webpack 5 behoben werden.

Aus Frontend-Sicht handelt man sich mit WebPack als Task Runner eine wackelige Plattform und eine hohe Abhängigkeit von der Weiterentwicklung notwendiger WebPack-Modulen ein (s.o., das Desaster rund um ExtractTextWebpack in WebPack 4). Man wechselt also seine Grunt-/Gulp-Abhängigkeit gegen WebPack-Fesseln ein.

An jenem Abend wurde mir dann klar, dass es nur einen Weg gibt, um die Abhängigkeiten zu reduzieren und flexibel zu bleiben: npm-Skripts.

npm basiert auf „pures“ NodeJS. Eingehängte Module können Shell- oder NodeJS-Skripts sein. Es werden keine speziellen Wrapper gebraucht, um sie für einen Grunt- oder Gulp-Task Runner lauffähig zu machen.

Dieser „Down to the Metal“-Ansatz stärkt zu dem das Kennenlernen der Shell und den grundlegenden NodeJS-Modules zB rund um das Datei-System.

Bookmarks