Von dem einen „Big Ticket“ bin ich zum nächsten „Big Ticket“ gerutscht – T-Shirt-Size XXL, jeweils zwei bis drei Wochen am Stück. Das zweite Ticket war/ist befriedigender als das erste Ticket gewesen. Ersteres ist zum Testen eine völlige Blackbox, weil die Geolocation des Users und die Länderversion der Website die Schlüssel zum Feature bilden – und sich beides schlecht testen lassen.

Das zweite Ticket macht mich glücklicher, weil die Überarbeitung des betreffenden Features, dieses wirklich auf allen Ebenen wesentlich besser macht.

In den nächsten Tagen wird es Diskussionen geben, ob wir an einigen Stellen von serverseitigen zum clientseitigen Rendering wechseln – zumindest für einige Code-Schnippsel. Wir verwenden es bereits an einigen Stellen – aber mehr als Improvisorium, weil es an einigen Stellen für das Backend größere Umbauarbeiten erfordert hätte. Nun geht es um die Frage, ob wir es bewusst als Werkzeug aufnehmen und backendseitig eine entsprechende API anfangen.

Ich bin grundsätzlich kein großer Freund von clientseitigen Rendering. Dieser Tage erschien auf CSS-Tricks ein Artikel, der a bisserl auf meine Bedenken einzahlt: „radEventListener: a Tale of Client-side Framework Performance“. Es spiegelt nicht ganz unser Szenario ab, weil es um den Einsatz größerer Frontend-Frameworks wie React und Preact geht.

Aber der Schmerz ist ein ähnlicher: warum den Client etwas machen lassen, wofür der Server qua Ressourcen, besser ausgestattet ist? Warum ein zweites Repository für Partials verwalten? Da komm‘ ich schwer aus meiner Haut als Dogmatiker raus.

Immerhin keine 30+xº C mehr. Mein Arbeitszimmer und das Schlafzimmer sind im ersten Stock und ich habe knapp zehn Tage lang, den ersten Stock nie kühler als 28 Grad bekommen. Mein Endreihenhaus ist mit seiner fensterlosen Giebelseite komplett gen Süden ausgerichtet. Das Haus heizt sich auf. Im Erdgeschoss sind es dann frische 25–26º C, aber der 1te Stock: chancenlos. Immerhin habe ich einen leisen Ventilator, mit dem ich nachts schlafen konnte.

An diesem Wochenende habe ich angefangen, das Code-Projekt dieses Blogs zu aktualisieren. Einige CSS-Petitessen gemacht, aber vor allem den Workflow von Grunt weg, hin zu NPM-Skripts gewechselt. Dabei kommt jetzt erstmals bei mir auch ein NPM-basierender Watch-Prozess zum Einsatz.

Ich hatte kurz überlegt, ob ich Rome an den Start bringen sollte. Aber das Projekt sieht abseits von Javascript, noch nicht weit genug aus, um wirklich die komplette Frontend Development Toolchain abzubilden.

Toolchain, Schmuchain. Zwei Blogeinträge von Jeremy Keith verdeutlichen: Werkzeuge der Frontend-Entwicklung sind da, um wieder zu gehen. So passiert mit jQuery, dass inzwischen i.d.R. nicht mehr benötigt wird, weil die nativen Javascript-Methoden bis runter IE11 gut genug sind. Keith sieht die gleiche Entwicklung bei Sass vs CSS – als Sass-Fan bin ich über diese Perspektive nicht ganz so erfreut.