Ein Rant? Ein Hilferuf? Ein Schrei nach… ja was denn? Ich weiss es noch nicht, ich schreibe jetzt einfach mal darauf los und vielleicht weiss ich am Ende des Textes, was da eigentlich soll. Aber: Etwas ist faul im Staate Webentwicklung und ich kann da nicht länger meinen Mund halten, auch wenn es vielleicht einigen Kollegen auf die Füße tritt.

Anlass dieses Textes ist eine Projektanfrage, die ich gerade auf dem Tisch habe. Ein (durchaus spannender) $Kunde hat eine (durchaus attraktive) Website, die vor ca. zwei, drei Jahren von einer (durchaus hippen) $Agentur im Rahmen eines kompletten Identity-Relaunches, der viel mehr umfasste, als das Web, realisiert wurde. Offenbar hat $Agentur nicht nur konzepiert und gestaltet, sondern das Ding auch In-House entwickelt.
Jetzt kommen wir schon zu Beef No.1, den ich öfters erlebe, und wo ich mich frage, Leute, wie kann das sein:
Mit Übergabe der Website an den $Kunden war das Verhältnis beendet. Maintenance, Weiterentwicklung, mithin DIESCHEISSEDIEMANVERZAPFTAUCHSELBSTAUSBADEN war nie Teil des Deals. Das ist so weit weg von meinem Verständnis, was das Arbeiten am und mit dem Web und Websites angeht, dass ich da tatsächlich (und dieser $Kunde ist nicht der einzige, bei dem das so läuft), also da bin ich raus. Mental. Der Launch einer Website ist doch erst der *Beginn*, das ist niemals ein fertiges "Deliverable", das ist kein fertiges Produkt, was Du ab dem Moment des Launches dann für alle Zeiten as is benutzt. Eigentlich ein No-Brainer: Erst wenn die Site "lebt", erkennt man, ob die konzeptionellen und inhaltlichen Sachen so funktionieren. Man erkennt auch erst nach dem Launch, ob "die Besucher" mit der Site zurechtkommen. Bei einer Site mit Content-Management merkt man auch erst nach dem Launch, ob die Inhaltsmodule und die Möglichkeiten der Redaktion dem entsprechen, was damit produziert wird. Somit ist in meinem Verständnis der Launch einer Website nicht das Ende unserer Arbeit, sondern ein Zwischenschritt. Um so unverständlicher finde ich es, wieso es anscheinend so viele $Agenturen gibt, die sich maximal bis zum Launch involvieren (es gibt dann noch die anderen, die "nur" gestalten und sich schon nach der vermeindlichen "Design" Phase verdrücken, wenn es "nur noch programmiert" werden muss. Zum Glück sind die aber mittlerweile, zumindestens in meiner Erfahrungswelt, fast komplett verschwunden, weil es sich doch fast überall rumgesprochen hat, dass "Webdesign" und "Responsive Webdesign" nur in einer engen Verzahnung der einzelnen Disziplinen funktionieren).

Warum ich ich gerade an der aktuellen Anfrage so abarbeite, geht noch etwas weiter: Selbst wenn alle der oben genannten Faktoren passen würden, und es $Agentur und $Kunde gelungen ist, genau das anzuschieben, was sie brauchen und was genau so funktioniert, wie sich das alle erhofft hatten - selbst dann ist die "Site" niemals fertig, da nun externe Faktoren ins Spiel kommen. Technologie entwickelt sich weiter, die Geräte und Browser der Besucher verändern sich, die Server- und Scriptsprachen-Technologie wird andauernd aktualisiert, Sicherheitslücken entdeckt und geschlossen, etc pp. Natürlich kann man einen $Kunden damit alleine lassen, und mit Sicherheit gibt es nicht wenige, die das dann In-House machen wollen oder die erstmal die vermeindlich teure $Agentur nicht dauerhaft an der Backe haben wollen. It takes two to Tango, das ist mir schon klar. Aber ich habe es in den letzten Jahren zu oft erlebt, dass sich offenbar eine ganze Reihe von $Web$Agenturen so positionieren, dass Sie mehr oder weniger individuelle Sites entwickeln und dann den $Kunden noch einen schönen Tag wünschen. Da scheint auch ein Markt vorhanden zu sein.

Aber zurück zum vorliegenden Fall: Da kommt also $Kunde zu uns, mit der Anfrage, ob wir bei der Weiterentwicklung der Site helfen können, immerhin hat man das CMS-X und offenbar haben wir ja auch Expertise damit. Bloss sei das CMS ja schon ganz schön kompliziert und irgendwie können sie (die Redaktion) auch nicht die Sachen damit machen, die sie eigentlich machen müssten. Naja und ein paar Bugs und kleinere Darstellungssachen sind Ihnen auch aufgefallen. Eigentlich eine normale Anfrage, einzig dieses "das CMS ist aber kompliziert" liess mich aufhorchen.

Denn exakt dieses CMS nutzen wir immer, wenn wir schlanke und intuitive Inhaltspflege für individuelle Websites brauchen, und in nunmehr fast zehn Jahren haben wir immer das Feedback bekommen, dass sich da ohne Einarbeitung und auch für neue Kollegen quasi direkt gut mit arbeiten lässt. Also habe ich mir aus Interesse die Site - oder das, was man halt so von aussen im Browser erkennen kann - genauer angeschaut. Es gibt ja die ein oder andere Stelle, wo man das CMS "riechen" kann, selbst wenn es keine offensichtlichen "Powered by" oder "meta creator" Hinweise gibt. Und nach dieser ersten oberflächlichen Betrachtung zeigte sich, dass es sich offenbar um eine JavaScript "App" handelt, und das CMS "nur" Headless als Datenlieferant dient.

Das ist ein durchaus angesagter und gerade sehr populärer Ansatz in einer bestimmten Ecke meiner Entwickler-Timeline, aber doch nicht, wenn man eine umfangreiche, aber eher "Brochure"-artige Website macht? Und jetzt kommts: 90% der Issues und "Bugs" und/oder der Kritik der Redaktion an Dingen, die nicht so funktionieren, wie sie es mittlerweile brauchen, hängt genau in diesem Stack. Die Abkopplung des CMS, die Entscheidung, für das Frontend eine komplett eigene Schicht mit ihrer eigenen Komplexität einzuziehen, verhindert momentan, dass man mit "normalem" Aufwand die Probleme des $Kunden gelöst bekommt. Ich sehe NULL Vorteil in dieser Entscheidung, die $Agentur da mal getroffen hat, ausser, dass man halt eben "Technique de jour" mal einsetzt (und smoothe Page-Transitions hat).
Ich greife jetzt etwas vor, aber nachdem wir dann auch mal Einblick in die Code-Basis bekommen haben, entsteht der Eindruck, dass man sich da $Agentur-seitig so schnell wie es irgendwie geht aus der drögen PHP/MySQL Welt des CMS rüber in den offenbar besser beherrschten Node/JS Stack bewegt hat, und dabei die Möglichkeiten, die das CMS eigentlich bietet, an vielen Stellen (wie ich finde) unnötig verkompliziert. Also nicht, dass die da prinzipiell schlechte Arbeit gemacht hätte, ganz im Gegenteil, aber ich finde halt, dass da schon ganz weit vorne irgendwas verkackt wurde in Hinblick darauf, wie sich dann die Site für die Redaktion nutzen lässt.
Und da sind wir wieder beim eingangs kritisierten "mir doch egal, was nach Launch passiert" - und das finde ich echt schlimm. Hier wurde vermutlich richtig viel Kohle versenkt, für etwas, das letztlich, wenn ich mir die Issueliste des $Kunden so ankucke, eigentlich wenig mehr im Interesse des $Kunden macht, als gut auszusehen (und smoothe Page-Transitions…).

Völlig unverständlich ist mir, dass $Kunde noch nicht mal wusste, mit was er es eigentlich zu tun hat und davon ausging, dass das bei CMS-X eben so sei. Wie gesagt, es gehören immer mehre Seiten dazu und ich weiss natürlich nichts über die initiale Aufgabenstellung, die Rahmenbedingungen der Auftragserteilung etc pp. Aber das, was ich da gerade sehe, ist böse gesagt:

Supergeiler Moderner Webstack um des supergeilen modernen Webstacks Willen, aber 500m am Kundenzweck vorbeigeworfen.

Meh. Ich mag den Current State Of WebDev nicht mehr.

Dave Rupert beschreibt das ziemlich gut:
… If there’s an allegory for what I don’t like about modern day web development, this is it. You want to use three tools, but you have to know how to use twenty tools instead.

Nur das hier noch dazu kommt, dass das so überhaupt keinen Sinn macht, diese Komplexität hier einzuführen, wo es nicht um eine mega-interaktive Webapp geht, sondern um eine WebSITE.
Hrgtnchml.

Immerhin bin ich mit meiner Befindlichkeit nicht alleine, scheints

Es gibt aber auch Szenarien, wo die Abkopplung des Frontends sinnvoll erscheint

🤷🏼‍♂️

Und auch wenn ich mich hier gerade an diesem Problem abarbeite, weil da der JS App part nervt, ist das Problem nicht, welche Technik, oder welche Architektur da gewählt wurde, sondern dass es offenbar nicht für den Zweck passt. Das Problem gibt es genauso, wenn man meint, alles mit WordPress befeuern zu können oder für eine Website mit zwei Abschnitten und einem Kontaktformular ein TYPO3 wählt. Oder, wie ich auch schon erlebt habe $Kunde unbedingt eine 'Website mit CMS' haben will, dann aber über Jahre nichts darin selbst macht. Daher finde ich es auch erstaunlich, wenn potentielle $Kunden gezielt nach einer 'WordPress' oder 'TYPO3' Agentur suchen, obwohl sie noch gar nicht wissen, wo die Webreise hingeht.

Photo by Austrian National Library on Unsplash