Es ist noch nicht so lange her, da war JavaScript für viele .NET-Entwickler ein eher unappetitliches Nebenprodukt von ASP.NET WebForms. Die Ursünde von JavaScript steht in einer Reihe mit der Darreichung des verbotenen Apfels vom Baum der Erkenntnis: JavaScript ist nicht streng typisiert und bietet Freiheiten, nach denen der .NET-Entwickler nie gefragt hat. Obendrein beschleicht ihn schon nach seiner ersten Zeile JavaScript-Code das ungute Gefühl, sich einen nicht zu testenden Wartungsalptraum eingehandelt zu haben, der ihn bis in den Schlaf verfolgen wird.
Nicht viel anders verhält es sich mit HTML und CSS, die dem gestandenen .NET-Entwickler wie die hässliche Nachgeburt des Internetzeitalters erscheinen. Damit konstruierte Seiten besitzen nach seiner Erkenntnis die Unart, sich prinzipiell völlig anders als gedacht darzustellen – und das sowieso noch einmal unterschiedlich in jedem Browser, wenn nicht gar in jeder Browserunterversion.
Umso deprimierender mag es für den .NET-Entwickler sein, dass dieses Konglomerat aus JavaScript und HTML/CSS, welches aus seiner Sicht längst zurecht von der Bildfläche hätte verschwinden sollen, sich auf eben dieser Bildfläche breitmacht wie kein anderer Technologie-Stack. Was soll der .NET-Entwickler tun, wenn er von seinem Arbeitgeber oder Kunden zu dem aberwitzigen Unterfangen getrieben wird, ausgerechnet in den Giftschrank der clientseitigen Web-Alchemie zu greifen, um eine Software von nennenswerter Stabilität zu entwickeln?
"Das Blau ist mir nicht blau genug", schreibt mein Kollege Sven Martens. Ach, wenn es denn nur das Blau wäre! Manch ein Backend-affiner .NET-Entwickler, der bislang erfolgreich einen Bogen um das ganze "JavaScript-Geraffel" gemacht hatte, sieht bei seinen ersten, von leidenschaftlicher Verachtung begleiteten Schritten in der bunten Welt der vermeintlich modernen Web-Technologien vor allem Rot.
Rettung ist in Sicht
Doch unser .NET-Entwickler ist längst nicht der einzige, der den Webtechnologie-Wildwuchs am liebsten mit Stumpf und Stiel ausreißen würde. Kluge Köpfe in aller Welt haben Ideen und Konzepte entwickelt, um diesen auf ein erträgliches Maß zurecht zu stutzen, bis JavaScript zumindest rudimentär einer höheren Programmiersprache ähnelt. Typisierte Variablen müssen her, Vererbungshierarchien für dies und das, Model Bindings in alle erdenklichen Richtungen, eine Art querybasierende Abfragesprache, Code-Beautifier, Code-Minifier, Paketierer und so weiter.
Mehrmals in der Woche läuft der Arbeitsrechner heiß, wenn die neuesten Schmerzlinderungen über NuGet ihren Weg ins Visual-Studio-Projekt finden – oder zumindest ein Teil davon, beim Rest muss man dann noch selbst etwas Hand anlegen. Aber das ist ja kein Problem, man trägt sich einfach kurz in eine Mailing-Liste ein und schon wird man informiert, wann der nächste Nightly Build zum Download bereitsteht. Ab und zu – aber wirklich nur ganz selten – mag es vorkommen, dass ein Contributer aus Pakistan, Kirgisien oder der sächsischen Schweiz es bei seinem hehren Ansinnen, den Code nach dem Pfadfinderprinzip schöner zurückzulassen als er ihn vorgefunden hat, mit der Rückwärtskompatibilität nicht so genau nimmt. Oder es wird ein neues Feature eingebaut, das leider nur zu 99% mit einem anderen arbeitserleichternden Framework kompatibel ist. Alles halb so schlimm – denn auf der im Quellcode angegeben Webseite des jamaikanischen Autors, der scheinbar auch eine Surfschule und ein Blog für lustige Katzenbilder betreibt, heißt es schon seit einer Woche sinngemäß, dass eine Lösung in Arbeit wäre.
Wo gehobelt bzw. geframeworkt wird, da fallen Späne. Daran werden sich die auch Kollegen von der internen IT, denen nach Projektende die dankbare Aufgabe zufällt, dieses schöne Stück Software am Laufen zu halten und punktuell zu erweitern, schnell gewöhnt haben.
Auf zu neuen Ufern
Auf unseren .NET-Entwickler wartet indes die nächste Herausforderung, womöglich in Form eines weiteren Web-Projektes. Aber damit kennt er sich nun aus – dachte er zumindest, bis er feststellte, dass in seinem neuen Projekt nur 3 der 21 Frameworks und Tools zum Einsatz kommen, mit denen er sich sein erstes Web-Projekt erträglich gemacht hat. Dafür hat ein anderer Entwickler bereits vier Monate nach Projektstart 16 andere Helferlein eingebunden, die allesamt ähnlich vielsprechend und vergleichbar nützlich sind. Man versteht sich unter Gleichgesinnten, auch wenn man über die eine oder andere Entscheidung noch einmal diskutieren müsste. Da gäbe es zum Beispiel dieses Productivity Tool, mit dem der .NET-Entwickler im letzten Projekt schon ein paar Nächte lang Erfahrung gesammelt hat. Das hat nämlich dieses eine geniale Feature, ohne dass man heutzutage gar nicht mehr auskommen kann. Zum Glück ist der andere Entwickler in diesem Punkt ganz offen und es macht ihm auch nichts aus, dass die bereits vorhandene Code-Basis dafür etwas umgestrickt werden muss. Im Grunde wollte er sich sowieso noch in dieses neue Tool einarbeiten, es fehlte ihm bislang einfach nur die Zeit dafür. Die Bedienung der anderen Tools und Frameworks erlernt sich ja auch nicht von selbst.
Außerdem hat er Ärger mit dem Kunden, weil seit dem letzten Skript-Update in unregelmäßigen Abständen ein Testbild mit einer surfenden Katze in der Produktgalerie erscheint. Aber auch dieses Problemchen wird nach der Einführung des neuen Tools bestimmt behoben sein.