Der Hype um browserseitige Programmierung ebbt nicht ab. Natürlich hatte ich schon JavaScript geschrieben, jQuery verwendet und die Webseiten so lange gedengelt, wie bis sie funktioniert haben, fremden JS-Code gefixt weil der Kollege unabkömmlich in anderen Projekten versenkt wurde oder mich über nicht erwartetes Verhalten des Codes in einem neuen Browser gewundert.

Frontend-Entwicklung als eigene Domaine

Auf die Dauer ist das aber nicht nur unbefriedigend, sondern die wachsende Kommunikation mit den Frontend-Entwicklern erfordert eine tiefer gehende Kenntnis von der Programmierung im Browser. Die Weiterentwicklung in der IT haben den Frontend-Entwickler als vollständige Domaine die letzten Jahre herausgetrieben.

Es ist das Auseinanderentwickeln des klassischen Backends mit Frontend-Anhängsel und der Programmierung im Frontend selbst, die das Backend nur noch als JSON-Datenbelieferung betrachtet. Hier fehlt im alltäglichen Projektbetrieb spürbar eine Vermittlung dieser beiden Seiten. Aus der früheren Anforderung, dass der Frontend-Entwickler die fertige Oberfläche mit CSS und JS noch einmal schön anmalen soll, ist die Abstimmung der beiden Welten über Schnittstellen wie REST, ajax-Call, WebServices geworden.

Projektrisiko – Trennung beider Welten

Oft fehlen Entwickler, welche in beiden Welten zu Hause sind. Die wissen, wann es z. B. notwendig ist, dass man das Backend nicht mit ein und derselben Abfrage lahmlegt, sondern die Antwort cacht. Oder anders herum, die Webservice-Schnittstelle nicht zu fein oder zu grob granuliert, um dem Frontend die Aufrufe und Datenaufbereitung zu vereinfachen. Man kennt die Möglichkeiten und den Impakt von Anforderungen in der jeweils anderen Welt nicht genug.

Hier liegt nicht zuletzt ein größeres Projektrisiko. Der Code funktioniert auf Entwickler-Ebene prinzipiell. Proof of concept ist ok, die Implementierung stabil, der Jenkins ist grün und Sonar meldet keine großen Auffälligkeiten.

Der erste Lasttest

Dann aber kommt der erste Lasttest. Selbstverständlich viel zu spät, kurz vor Auslieferung wird er gemacht, weil dem Kunden die Ergebnisse des Lasttests laut Vertrag zustehen (Augenzwinker). Dann bricht plötzlich die Performance massiv ein und Fehler tauchen auf, die es vorher nicht gab. Dann ist guter Rat im Wortsinn teuer. Erwähnte ich schon, dass das Budget aufgebraucht ist?

Das ist dann genau der Augenblick, in dem sich alle am Code zusammensetzen und das Verhalten auf Backend-, Frontend- und Middelware-Ebene analysieren. Jetzt spricht man sich ab, wundert sich. Man unterhält sich nicht nur formal über die notwendigen Parameter der Schnittstelle, sondern deren Aufbau in die Tiefe, Zeitverhalten, Nebenläufigkeiten (ganz wichtig). Dies hätte eigentlich schon vor Monaten passieren müssen – eigentlich. Nun wird es stressig und wahrscheinlich teuer.

Vermittlungsebene

Es leuchtet jetzt ein. dass man von Anfang an jemanden dabei haben sollte, der sich in beiden Welten gut auskennt. Das sind oft genau die Kollegen, die man bei Problemen gerne befragt und die man hoffentlich jetzt mit hinzuzieht und es schafft, das Verhalten zu stabilisieren.

Das ist auch einer der Gründe gewesen, weswegen ich begonnen habe, mich noch einmal ganz grundsätzlich mit JavaScript resp. ECMAScript zu beschäftigen. Davon abgesehen, dass man sowieso von Zeit zu Zeit eine neue Programmiersprache lernen sollte.

Nach einigem Suchen auf Youtube fand ich folgenden Beitrag ‚JavaScript: Understanding the Weird Parts – The First 3.5 Hours‘. Der erste Teil ist kostenlos und hat mich überzeugt.