Geschwindigkeit zählt

Im Internet kursieren zahlreiche Blogartikel und lesenswerte Auszüge aus Büchern, die zum gleichen Schluss kommen: Ein Computersystem hat ungefähr 0,1 Sekunden, um auf die Aktion eines Benutzers zu reagieren, ohne dass dieser die Verzögerung wahrnimmt. Punktuell auftretende Verzögerungen, wie sie beispielsweise beim Speichern einer größeren Datenmenge auftreten, sind für den Benutzer in den meisten Fällen noch nachvollziehbar. Sehr viel schwieriger ist es zu vermitteln, wenn eine Anwendung mehrere Sekunden für den Wechsel zum nächsten trivialen Datensatz benötigt oder eine gefühlte Ewigkeit damit verbringt, den Inhalt einer gerade geöffneten Drop-Down-Liste vom Server zu laden. Während die meisten Firmen ihren Kunden solche Antwortzeiten nicht zumuten, hält sich bei unternehmensintern genutzter Software hartnäckig die Annahme, dass die Geschwindigkeit im Grunde egal ist, solange die Software funktioniert. Das war 1982 schon falsch und ist heute, da schnelle und leicht zu bedienende Elektronik längst zur Massenware geworden ist, falscher denn je.

Die gute Nachricht ist, dass Single Page Applications die Geschwindigkeitsprobleme, die viele klassische Web-Anwendungen im Laufe ihrer Weiterentwicklung bekommen, fast immer wirkungsvoll vermeiden. Der Schlüssel dazu ist die Verlagerung von großen Teilen der Programmlogik auf den Client. Die optimierten JavaScript-Engines moderner Browser und der hohe Reifegrad von umfangreichen JavaScript-Bibliotheken wie jQuery ermöglichen heute so niedrige Antwortzeiten, wie man sie bis vor zwei, drei Jahren eigentlich nur von proprietären Browser-Plugins gewöhnt war. JavaScript ist zwar nach wie vor keine RIA-Technologie im engeren Sinne, aber vieles von dem, für das man bis vor kurzem RIA-Technologien zu brauchen glaubte, vom interaktiven Web-Charting bis hin zum Browser-Spiel, wird heute schon zunehmend oder fast ausschließlich mit JavaScript umgesetzt.

Ständig verbunden?

Die digitale Welt begleitet uns heutzutage in vielen Lebenssituationen, vom Strichcode gegen Baby-Verwechslung auf der Neugeborenen-Station bis hin zum QR-Code auf dem Grabstein. Doch auch unter weniger endgültigen Umständen ist man selbst in dicht besiedelten Gegenden wie dem Rhein-Main-Gebiet manchmal plötzlich offline, besonders unterwegs. Ein weiteres Phänomen sind von den Telefonanbietern beworbene Smartphone-Tarife mit LTE und Internet-Flatrate, bei der dann im Kleingedruckten zu lesen ist, dass die Geschwindigkeit nach Inanspruchnahme eines Datenvolumens von 200 MB für den Rest des Monats auf ca. 8 KB pro Sekunde gedrosselt wird. Aus diesen und anderen Gründen sind Webseiten und Web-Applikationen, die auf fast jede Aktion hin mit dem Server kommunizieren, für die mobile Nutzung nicht zu empfehlen.

Im Gegensatz dazu kommen Single Page Applications, die nach dem Thin-Server-Prinzip entwickelt worden sind, mit einem Minimum an Kommunikation zwischen Server und Client aus. Das bedeutet nicht, dass Single Page Applications per se offline genutzt weitergenutzt werden können, da hierfür vom Entwickler geeignete Voraussetzungen geschaffen werden müssen. Der Aufwand ist aber in den meisten Fällen überschaubar, sofern die Endgeräte, auf denen die Single Page Application verfürgbar gemacht werden soll, über einen HTML5-fähigen Browser verfügen. Ist dies der Fall, so können die Daten der Anwendung im Local Storage des Browsers zwischengespeichert und zu einem späteren Zeitpunkt mit dem Datenbestand des Servers abgeglichen werden. Falls mehrere Benutzer auf die gleichen Datensätze zugreifen oder sich die Datensätze auf Serverseite aus anderen Gründen verändern, kann hierdurch aber eine neue Komplexität entstehen, die bei der Entwicklung der Anwendung berücksichtigt werden muss.

One Application – Multiple Devices

Während der Markt für PCs und Notebooks seit Längerem schrumpft, liegen die Absatzzahlen für Tablet-PCs weit über den Prognosen. Gleichzeitig gibt es bei den Smartphones einen anhaltenden Trend zu Displaygrößen jenseits von 4 Zoll – bei manchen Modellen muss man sich inzwischen sogar fragen, ob es sich noch um ein Smartphone handelt. Software-Anbieter sehen sich in diesem Umfeld oftmals gezwungen, die gleiche Anwendung auf mehreren Plattformen in unterschiedlichen Programmiersprachen zu entwickeln. Die damit verbundenen Zusatzaufwände und –kosten sind beträchtlich, ebenso wie die damit oft verbundenen Verzögerungen in Punkto Time-to-Market.

Ein Ausweg aus diesem Dilemma können wiederum Single Page Applications sein, wenn auch nicht für jedes denkbare Szenario. Da sie im Browser laufen, muss man für Anwendungen, die den direkten Zugriff auf die Gerätehardware benötigen, Umwege wie den über Cordova (ehemals PhoneGap) gehen. Da es aber auf den meisten Plattformen möglich ist, in HTML und JavaScript geschriebene Anwendungen in eine native Hülle einzubetten, sind die Möglichkeiten inzwischen fast unbegrenzt. Spätestens seit Microsoft JavaScript zu einem Eckpfeiler für die App-Entwicklung unter Windows 8 gemacht hat, dürfte klar sein, dass der HTML/CSS/JavaScript-Technologie-Stack wie kein anderer von der Diversifizierung der Gerätetypen und Betriebssysteme profitiert hat. Single Page Applications sind innerhalb der Familie der JavaScript-basierenden Anwendungen die Variante, deren User Experience die größte Nähe zu nativen Apps verspricht, bis zu dem Punkt, an dem es fast nicht mehr möglich ist, diese voneinander zu unterscheiden.

Klarere Verhältnisse

Bei Vergleichen zwischen Silverlight und JavaScript wurde in der Vergangenheit oft hervorgehoben, dass Silverlight ein einheitliches Programmiermodell bietet, anders als JavaScript in Kombination mit einem serverseitigem Backend. Das ist zwar etwas kurz gegriffen, weil man Node.js außen vor lässt, aber zumindest für den .NET-Bereich stimmt das schon. Bei Single Page Applications nach dem Thin-Server-Prinzip besteht dieses Problem aber in weit geringerem Maße als beispielsweise bei klassischen ASP.NET-WebForms-Anwendungen. Das gilt insbesondere für die Code-Duplizierung zwischen Client und Server, etwa bei der Validierung der meisten Benutzereingaben. Bei einer Single Page Application nach dem Thin-Server-Prinzip sind die Zuständigkeiten klar zugunsten des Clients verteilt und die Kommunikation zwischen Client und Server findet über definierte Endpunkte statt. Somit lässt das Argument gegen den Durcheinander, das ursprünglich ein Argument für Silverlight und gegen Anwendungen mit hohem JavaScript-Anteil war, sich – mit ein paar Abstrichen – inzwischen auch als Argument für Single Applications und gegen den für ASP.NET-WebForms-Anwendungen typischen Code-Mischmasch verwenden.

Nachdem es in diesem Teil der Artikelserie in erster Linie um die Vorzüge von Single Applications ging, soll der nächste Teil den Herausforderungen, die ihre Entwicklung mit sich bringt, gewidmet sein.