Frontend-Entwicklung – webbasiert oder nativ?

In den letzten 3 Jahren hat die Beliebtheit von HTML5 und JavaScript zur Entwicklung von Web-Clients enorm zugenommen. Hauptgrund ist die sogenannte plattformunabhängige Lauffähigkeit, d.h. ein Browser-Frontend kann ohne Änderung auf verschiedenen Betriebssystemen ausgeführt werden. Auch der Prozess des Deployments, der bei nativen Anwendungen eine Installation einer neuen Version auf mehreren Geräten bedingt, reduziert sich bei Web-Clients auf die serverseitige Aktualisierung. Dies ist ein positiver Aspekt, der zur aktuell hohen Popularität der webbasierten Anwendungsentwicklung beigetragen hat.

Um eine Plattformunabhängigkeit für eine Frontend-Applikation zu erreichen hatte die Softwareindustrie bereits in der Vergangenheit vielversprechende Lösungsansätze, wie die Browser-Plugins Flash und Silverlight, parat. Silverlight ist auf den Plattformen Windows, MacOS und Linux verfügbar und erlaubt die komfortable Programmierung in C# und dem .NET Framework. Silverlight ist für die Filmindustrie erstaunlicherweise immer noch erste Wahl, vor allem wegen der DRM-Kopierschutzfunktion, die HTML5 nicht unterstützt. Dennoch wird Silverlight seit der Version 5 von Microsoft nicht mehr weiterentwickelt und es wird von keinem Browser auf mobilen Plattformen unterstützt. Grund war der Strategiewechsel von Microsoft bei der Einführung von Windows 8. Seitdem forciert Microsoft verstärkt die webbasierte Entwicklung mit HTML5 und JavaScript (siehe Blogpost Microsofts neue Windows 8 Welt für Entwickler).

Was macht das Entwickeln mit HTML5 und JavaScript für den Frontend-Entwickler so interessant? Ist es die praktische Möglichkeit, den Code einfach zu ändern und per Klick auf die F5-Taste im Browser sofort zu testen? Lange Kompilierungszyklen, wie bei umfangreichen .NET-Anwendungen üblich sind, kennt der Webentwickler nicht. Im Gegensatz zu HTML5, das etliche Neuerungen, wie zum Beispiel neue Multimedia und Animationen beinhaltet, ist JavaScript eigentlich immer noch auf dem Stand von vor 10 Jahren. Erst durch das Angebot von JavaScript Frameworks wurde die Erstellung webbasierter Anwendungen für die Frontend-Entwickler interessant. Schließlich ist HTML5 eigentlich nicht für die Beschreibung dynamischer Webseiten konzipiert und dieser Umstand bedarf der Hilfestellung durch JavaScript-Code. Bei komplexeren Anwendungen reicht ein Knowhow über HTML5, CCS3 und JavaScript allein nicht aus, um den Code sauber und wartbar zu halten. Nicht nur deshalb sind eine Vielzahl von Frameworks in den letzten Jahren wie Pilze aus dem Boden geschossen.

Hier eine Auswahl der aktuell angesagten JavaScript Frameworks:

• JQuery – Funktionssammlung für Navigation und Manipulation der DOM-Syntax,Event-Handling, Animationen u.a.
• Prototype – bietet u.a. Unterstützung für klassische objektorientierte Programmierung
• Mootools – ermöglicht u.a. Drag & Drop, Sliding und Morphing
• Angular.js – dient zur Erstellung von Komponenten basierend auf dem MVC Modell, unterstützt Dependency Injection
• Knockout.js – dient der Trennung von UI und Logik, deklaratives Databinding, MVVM Pattern
• Twitter Bootstrap – Unterstützung für responsive Layouts
• Ext JS  – Sammlung von UI-Widgets für Business-Anwendungen

Einerseits erleichtern derart Frameworks dem geplagten JavaScript-Entwickler die Arbeit erheblich. Andererseits kann diese mittlerweile immense Flut an Code-Sammlungen auch Probleme für den Entwickler von Frontends mit sich bringen. Für jedes eingesetzte Framework benötigt der Entwickler eine Einarbeitungszeit. Eine Kombination diverser Frameworks kann unter Umständen zu Inkompatibilitäten und Verschlechterung der Performance führen („Javascript library conflicts are not uncommon“). Ist der aktuelle Hype um die webbasierte Entwicklung nicht stark übertrieben? Selbst Marc Zuckerberg, der Chef von Facebook, der ebenfalls auf den HTML5/JavaScript-Siegeszug aufgesprungen war, soll Ende 2012 zugegeben haben, dass diese Entscheidung ein großer Fehler war. Je nach Anforderungslage gibt es, trotz des vermeintlich höheren Entwicklungsaufwandes, gute Gründe sich für eine native Anwendungslösung zu entscheiden.

Gründe für native Frontend-Apllikationen

• Die Standardisierung von HTML5 ist einerseits noch nicht abgeschlossen und anderseits sind die auf dem Markt befindlichen HTML5-kompatiblen Browser leider in der Praxis ganz und gar nicht kompatibel untereinander. Dies führt zwangsläufig zu einer mehrgleisigen Implementierung des Client-Codes und somit zu zusätzlichem Programmieraufwand. Der Aufwand für Tests und Bugfixing wird unterschätzt. Laut einer Studie der University of British Columbia weisen 99 der Top 100 Seiten im Netz JavaScript Fehler aus.

• Bei Applikationen, die im Browser-Fenster laufen existieren klare Einschränkungen beim Zugriff auf Hardware. Bedingt durch das Sandbox Sicherheitskonzept der Browser, können webbasierte Anwendungen nicht auf Gerätehardware zugreifen. Obwohl man mit HTML5 und JavaScript mittlerweile auch die Multitouch-Fähigkeit der Geräte nutzen kann, kollidiert diese Technik mit den Bedienfunktionen des Browsers. In der Webentwickler-Community wird hier fleißig mit neuen Lösungsansätzen experimentiert. Oft funktionieren diese Lösungen, wie z.B. die JavaScript-Bibliothek Hammer.js, wiederum nur mit einigen ausgewählten Browsern.

• Die User Experience bei webbasierten Anwendungen kann im Vergleich zu einer nativen Implementierung kaum mithalten, da man bei Browser-Anwendungen typischerweise längere Reaktionszeiten in Kauf nehmen muss. Neue Konzepte zum Thema „Responsive Webdesign“ (z.B. Twitter Bootstrap) versprechen Besserung. Allerdings gibt es das nicht geschenkt. Die Implementierung zusätzlicher Frameworks bedeutet Einarbeitung und weiteren Programmieraufwand. Trotz dieser Optimierungsmöglichkeiten haben Konzerne wie Amazon, LinkedIn oder Xing zusätzlich zu ihren webbasierten Lösungen native Apps für alle Mobile-Plattformen entwickeln lassen.

• Frontend-Entwickler, die auf Microsoft Technologien setzen, haben die freie Wahl, entweder C# in Kombination mit XAML oder HTML mit JavaScript zu verwenden, um native Apps für den Windows 8 Store zu erstellen. Dennoch bevorzugt, laut einer Untersuchung von ZDNet, die große Mehrheit der Entwickler eindeutig den Lösungsweg mit C# und XAML. Nicht ohne Grund, denn der Sprache JavaScript fehlen u.a. etablierte Konzepte wie Typsicherheit, Interfaces, Generics und „echtes“ Multithreading. Derart Konzepte sind meines Erachtens unerlässlich für die Strukturierung komplexer Geschäftsanwendungen.

• Im Gegensatz zu C# und Java ist JavaScript untypisiert. Dadurch werden einige Programmierfehler nicht zur Kompilierzeit sichtbar, sondern können erst zur Laufzeit entdeckt werden. Dies birgt Potential für Fehler, die erst sehr spät, unter Umständen sogar erst nach dem Release entdeckt werden können, was einen deutlich höheren Aufwand für das Beheben von Bugs zur Folge hat.

• Webbasierte Anwendungen mit HTML5 und JavaScript verfügen mittlerweile über neue Möglichkeiten Daten offline vorzuhalten, allerdings stellen unterschiedliche Konzepte der Browser-Hersteller (wie LocalStorage, IndexdDB, Web SQL Database, AppCache etc.) den Webentwickler vor eine Herausforderung. Native Applikationen bieten in Offline-Szenarien insbesondere bei großem Datenvolumen und asynchroner Datenübertragung vom Client zum Backend nach wie vor die bessere Unterstützung.

• Beim Einsatz von HTML5 und JavaScript bei der Entwicklung von Frontends müssen zusätzliche bzw. im Vergleich zu nativen Anwendungen aufwändigere Maßnahmen u.a. für die Abwehr von SQL-Injection oder Cross-Site-Scripting Angriffen oder bedingt durch Einschränkungen bei Cross-Domain Zugriffen eingebaut werden.

Hybride Frontends für Mobile Apps

Eine Alternative zu den beiden Möglichkeiten sind hybride Frontendappliaktionen. Erwähnenswert ist das Produkt Xamarin, das die einheitliche Entwicklung mit der Programmiersprache C# erlaubt. Allerdings muss man auch hier für jede der unterstützten Plattform Android, iOS und Windows Phone den Aufbau der UI mit deren Steuerelementen jeweils neue beschreiben. Der Vorteil ist die gemeinsame Code-Basis für die UI-Logik, die für alle Plattformen nur einmal entwickelt wird.

Das Entwicklungstool Sencha Touch soll, eine einmal in HTML5 und JavaScript geschriebene App, auf  den mobilen Plattformen iOS, Android, BlackBerry und Windows Phone mit Hilfe PhoneGap als native Apps lauffähig machen. Sieht man genauer auf die Beispiel-Anwendungen hin, so wird nebenbei erwähnt, dass man sich auf „Sencha Touch -kompatible“ Browser wie Chrome und Safari beschränken soll. Ob eine Festlegung auf zwei Browser gut ist, sollte angesichts der Tatsache, dass noch weitere Browser mit entsprechenden Marktanteilen existieren und diese Marktanteile ständig in Bewegung sind, bezweifelt werden.

Alle drei Lösungen sind mit Lizenzkosten und/oder Kosten für die Erzeugung der App behaftet. Eine Erweiterung der PhoneGap-Lösung, die außerdem kostenfrei ist, kommt aktuell von Intel. Intel XDK ist eine komplette Lösung mit Open-Source Framework inklusive Simulator-, Editor- und Designer-Tool. Der Service zum Erstellen der App in der Cloud ist ebenfalls kostenlos.

Fazit

Jede der aufgeführten Technologien hat ihre Vor- und Nachteile. Somit gibt es keine Frontend-Lösung, die alle Einsatzszenarien und Anforderungen optimal abdecken kann. Man sollte sich im Klaren sein, dass beispielsweise ein Maschinenbauer, der seine Maschinen einheitlich mit Embedded Windows PCs ausgestattet hat, eigentlich keine webbasierte Oberfläche zur Steuerung und Visualisierung der Maschinen entwickeln sollte, da in diesem Fall einfach keine Plattformunabhängigkeit benötigt wird. Außer er hat ausschließlich HTML5 und JavaScript-Entwickler zur Hand. An diesem Beispielszenario kann man erkennen, das mehrere Faktoren Einfluss auf die Entscheidung zur Wahl der optimalen Technologie haben können. Folgende Vergleichstabelle soll die Entscheidungsfindung erleichtern: