Wie im vorangegangenen Teil dieser Artikelserie beschrieben, bieten Single Page Applications eine ganze Reihe von Vorteilen gegenüber klassischen Web-Anwendungen. Eines lässt sich von Single Page Applications allerdings nicht behaupten, nämlich, dass diese besonders einfach zu entwickeln sind.
Vorwissen erforderlich
Bevor man mit der Entwicklung von Single Page Applications beginnen kann, muss man sich solide Grundkenntnisse in den Web-Standards HTML(5), CSS und JavaScript angeeignet haben. Da pures JavaScript eine mühselige und fehleranfällige Angelegenheit ist, sollte man mit der Verwendung einer JavaScript-Bibliothek wie jQuery vertraut sein, die den Zugriff auf das Document Object Model (DOM) erleichtert und vereinheitlicht. Die heute gängige Form der Entwicklung in JavaScript nutzt zudem dessen Fähigkeiten als dynamische, funktionale Sprache mit Prototyping voll aus und ist nicht mit dem Codieren simpler Hilfsmethoden zu vergleichen. Darüber hinaus sollte man sich der Herausforderungen der protokollnahen Web-Entwicklung bewusst sein, insbesondere der Statuslosigkeit des HTTP-Protokolls und der asynchronen Kommunikation zwischen dem Browser (Client) und dem Web-Server.
Dieses Wissen kann nicht bei jedem Entwickler als vorhanden vorausgesetzt werden. Speziell für ASP.NET WebForms lässt sich sagen, dass Microsoft große Anstrengungen unternommen hat, um die Feinheiten der Web-Programmierung vor dem Entwickler zu verbergen und ein windowsähnliches Programmiermodell im Web zu ermöglichen. Jeder, der längere Zeit mit ASP.NET WebForms gearbeitet hat, weiß, dass das nur bedingt funktioniert, sich aber mit Workarounds und/oder der exzessiven Nutzung der Session meistens recht gut in den Griff bekommen lässt. Bei der Entwicklung einer Single Page Application kommt man hingegen nicht umhin, sich um eine Reihe von Aufgaben selbst zu kümmern, die einem von ASP.NET WebForms abgenommen werden. Darin liegt aber auch zugleich die Chance, wieder der eigene Herr über den Kontrollfluss innerhalb der Web-Anwendung zu werden, anstatt sich darauf zu verlassen, dass ASP.NET WebForms sich in allen erdenklichen Szenarien wie erwartet verhält.
Strukturierung ist essenziell
Niemand ist heutzutage noch darauf angewiesen, seinen Code in einem einfachen Text-Editor schreiben zu müssen. So bietet z. B. Microsoft Visual Studio eine recht gute Unterstützung für die Entwicklung on JavaScript, von Autovervollständigung (IntelliSense) über Syntax-Fehlererkennung bis hin zur Möglichkeit, den Code zur Laufzeit mit Breakpoints zu debuggen.
Bei der Strukturierung des Codes und dessen Aufteilung auf eine oder mehrere Datei(en) hat man hingegen die totale Freiheit. Das mag zwar im ersten Moment angenehm sein, führt aber in Projekten mit mehreren Beteiligten schnell dazu, dass sehr unterschiedliche Systematiken auf einander treffen. Im schlimmsten Fall kann der Versuch eines erfahrenen Entwicklers, seinen Code möglichst systematisch aufzubauen, einem unerfahrenen Entwickler wie ein Buch mit sieben Siegeln erscheinen. Deshalb ist das Festlegen verbindlicher Coding Guidelines in größeren Projekten unverzichtbar. Das gilt zwar ohnehin für alle Programmiersprachen, bei einer flexiblen Skriptsprache wirkt sich der Verzicht auf ein gemeinsames Grundgerüst besonders schnell negativ aus. Wenn ein Testing-Framework zum Einsatz kommen soll, was bei unterschiedlichen Arten von Anwendungen auch unterschiedlich wichtig ist, sollte man sich möglichst früh dafür entscheiden – am besten, bevor die erste Zeile Code geschrieben wird.
JavaScript-Bibliotheken – Fluch und Segen zugleich
Der Großteil der im letzten Abschnitt getroffenen Aussagen zur Strukturierung von JavaScript-Code lässt sich auch auf die Einbindung von JavaScript-Bibliotheken übertragen. Von diesen gibt es inzwischen eine unüberschaubare Anzahl, mit der so gut wie jedes in der Web-Entwicklung auftretende Problem mit wenigen Funktionsaufrufen gelöst werden kann. Und das Beste: Fast alle Bibliotheken sind für private wie kommerzielle Projekte frei verwendbar. Doch leider hat die Sache gleich mehrere Haken: Fast immer gibt es nicht nur verschiedene Lösungen, sondern verschiedene Lösungswege, die möglicherweise unterschiedlich gut mit dem Rest der Anwendung harmonieren. Das gilt auch für das Zusammenspiel der JavaScript-Bibliotheken untereinander, beispielsweise in Randbereichen wie Lokalisierung und Mehrsprachigkeit. Die populärste Lösung muss nicht immer die am besten geeignet sein, auch wenn hohe Downloadzahlen auf Sourceforge & Co. und eine hohe Anzahl Suchmaschinentreffer oft für einen recht hohen Reifegrad der Bibliothek sprechen. Durch die Quelloffenheit von JavaScript lässt sich miese Code-Qualität viel schwerer als bei vorkompilierten Programmiersprachen kaschieren.
Das mit Abstand größte Problem im Zusammenhang mit JavaScript-Bibliotheken liegt allerdings in ihrem unüberlegten Einsatz in Situationen, in denen man mit geringem Mehraufwand auch mit vorhandenen Mitteln zum Ziel kommen würde. Eine Anwendung, die nur wenige Benutzereingaben zulässt, benötigt kein extrem mächtiges Validierungs-Framework, ebenso wenig wie eine Anwendung, deren Bedienelemente ohnehin zu winzig für die Verwendung mit Touch-Geräten sind, spezielle Gesten unterstützen muss. Das soll aber kein Plädoyer gegen JavaScript-Bibliotheken sein. Die Verwendung von jQuery oder vergleichbaren Alternative ist eigentlich immer sinnvoll, weil dadurch die Entwicklung in JavaScript und der Zugriff auf viele der typischsten HTML-Features vereinfacht und vereinheitlicht wird. Da gerade bei Single Page Applications sehr viel auf Client-Seite stattfindet, machen bestimmt auch noch einige weitere Bibliotheken Sinn, wenn sich dadurch wichtige bzw. häufig benötigte Aspekte innerhalb der Anwendung deutlich besser umsetzen lassen.
Man sollte aber nicht aus den Augen verlieren, dass mit jeder zusätzlichen Bibliothek Komplexität der Anwendung und der Dokumentationsbedarf steigen. Große Software-Projekte werden oft mehrere Jahre später als ursprünglich geplant abgelöst. Für webbasierende Anwendungen bedeutet das fast immer, dass sie mehrere Browser-Generationen überdauern werden. Die unbedachte Einbindung zu vieler Bibliotheken, vor allem solchen, bei denen nicht absehbar ist, ob sie in ein paar Jahren noch jemand pflegen wird, kann nur in eine Sackgasse führen. Und das ist genau die Art von Sackgasse, die die Umstellung vieler Unternehmensanwendungen von Internet Explorer 6 auf eine neuere Version zu einem sehr aufwändigen und sehr teuren Unterfangen gemacht haben und machen.
Es muss nicht immer MVC sein
Bei Microsoft ist man sich der wachsenden Bedeutung von Single Page Applications bewusst. Diese waren in letzter Zeit immer wieder Gegenstand von Microsoft-Vorträgen, wie dem von Steve Sanderson bei den Tech Days 2012. Mittlerweile bietet Microsoft sogar ein ASP.NET Single Page Application Template für Visual Studio 2012 bzw. Web Tools 2012 zum Download an. Auffällig ist, dass Single Page Applications bei Microsoft immer oder fast immer in Kombination mit ASP.NET MVC thematisiert werden. Diese Verbindung ist naheliegend, weil ASP.NET MVC direkt auf dem Web-Programmiermodell aufbaut, ohne, wie bei ASP.NET WebForms, eine Abstraktionsebene darüber zu konstruieren. Da aber für Single Page Applications in der Thin-Server-Variante das Backend keine große Rolle mehr spielt, können diese grundsätzlich auch auf Basis von ASP.NET WebForms realisiert werden. Dies kann besonders für Entwickler, die sich nicht zusätzlich in ASP.NET MVC einarbeiten möchten, oder innerhalb von Projekten, in denen ASP.NET WebForms gesetzt ist, ein gangbarer Weg sein.
Der praktische Teil dieser Artikelserie, der im nächsten Teil folgen soll, wird deshalb bewusst mit ASP.NET WebForms umgesetzt werden. Die Unterschiede zu einer Umsetzung in ASP.NET MVC werden jedoch, so viel sei an dieser Stelle schon verraten, überschaubar sein.