Apps mit JavaScript: Ein Status-Update zu hybriden Apps

JavaScript zählt heutzutage zu einer der beliebtesten Programmiersprachen. Längst findet JavaScript seine Verwendung in allen technischen Bereichen. Ob nun Webseiten, Desktop-Programme, IoT-Projekte, Server, Robotik oder mobile Anwendungen; für all diese Bereiche gibt es Frameworks, die die Entwicklung mittels JavaScript ermöglichen.

Das Thema App-Entwicklung mit JavaScript soll in dieser kleinen Artikel-Serie namens Apps mit JavaScript einen speziellen Platz finden. Wir werden Möglichkeiten, negativen und positiven Erfahrungen sowie Empfehlungen der Entwicklung mit JavaScript beschreiben. Als erstes wollen wir jedoch den Stand hybrider Apps aufzeigen, denn es hat sich einiges getan in den letzten Jahren.

 

Die ersten Gehversuche mit hybriden Apps

Das Technische zuerst. Hybride Apps sind im Grunde genommen Web-Applikationen, die in einem App-Container laufen. Wird der App-Container gestartet, wird die bereitgestellte Web-App in einem In-App-Browser dargestellt und kann von da an wie eine App verwendet werden. Der Vorteil dabei ist es nur eine einzige App zu entwickeln, welche auf verschiedenen Plattformen lauffähig ist. Eines der bekannteren Frameworks für solche App-Container ist Cordova.

 

“Hybride Applikationen sind aber performance-technisch schlechter als native Apps!” — Der kleine Nerd von nebenan.

 

Es ist schon richtig, dass hybride Anwendungen zu ihren Anfangszeiten eine schlechte Performanz darboten. Das muss man ehrlicherweise zugeben. Man sollte sich jedoch auch klar machen, weshalb das so war: Neben fehlendem Support für native Funktionalitäten sowie fehlende nativ-wirkende Oberflächenelementen, war ein weiterer großer Störfaktor die Benutzerfreundlichkeit.

Damit der Browser oder die hybride App den Unterschied zwischen einem normalen Tap und einem doppelten Tap erkennen konnte, wurde ein 300ms Tap-Delay in gängigen Browsern implementiert. Wurde innerhalb der 300ms zweimal getappt, galt es ein Doppel-Tap, ansonsten war es ein normaler Tap. Dies war für Benutzer und Benutzerinnen recht nervig, denn obwohl man eigentlich immer nur einmal tappen wollte, mussten die 300ms abgewartet werden bevor die Aktion überhaupt vom Browser behandelt wurde. So eine Verzögerung hat einen maßgeblichen Einfluss auf das Erlebnis. Und die Kritik der Performanz gegenüber von nativen Apps blieb somit nicht aus: Es fühlte sich alles träge an.

Ein weiteres Manko waren die fehlenden UI-Elemente für die unterschiedlichen Plattformen. Dadurch, dass die Oberfläche auf HMTL basiert, konnte bei der Entwicklung nicht auf die nativen UI-Elemente von Android und iOS zurückgegriffen werden. Somit sahen hybride Apps nie wirklich “nativ” aus. Diese beiden Probleme waren ein zusammen ein großer Grund, wieso hybride Apps keinen richtigen Anhang fanden. Den Benutzern fehlte das Look & Feel einer nativen App.

Ein weiteres Problem war letztlich die mangelnde Unterstützung von nativen APIs. Der Programmcode, welcher im App-Container läuft, hatte keinen direkten Zugriff auf die Kamera oder das GPS-Modul. Diese Zugriffe mussten zuerst mit Hilfe von Cordova-Plugins ermöglicht werden. Bei neuen Features mussten dadurch Entwickler erstmal ein Cordova-Plugin implementieren, bevor das Feature verwendet werden konnte.

Alles in allem war es kein guter Start für hybride Apps. Obwohl sich Firmen wie Facebook davon viel erhofften, gaben sie 2012 bekannt, ihre mobilen Facebook-Apps nicht mehr als hybride Apps weiterzuentwickeln.

 

Die letzten Jahre

In den letzten 3 bis 4 Jahren hat sich jedoch viel in der hybriden App-Welt getan. Zum einen hat Android standardmäßig Chrome auf jedem Gerät installiert, welches als Webview für hybride Apps verwendet wird. Der Vorteil dabei ist nicht nur, dass Chrome viele CSS-Standards einhält, sondern auch die Browser auf allen Geräten stets aktuell hält und somit die gleichen Features auf allen Android-Versionen bereitstellt. Auf iOS wurde ein neuer In-App-Browser implementiert, welcher seit einigen Jahren verwendet werden kann.

Die neuen Browser sind essentiell für performante hybride Apps: Die 300ms Delays wurden entfernt, die CSS-Animationen wurden dank GPU-Unterstützung flüssiger und letztlich wurden Cordova-Plugins stets stabiler.

 

“Und was ist mit der UI und den nativen Funktionen?” — Der kleine Nerd von nebenan.

 

Hierfür gibt es insbesondere das Open-Source Framework Ionic, welches eine gute Arbeit leistet, mittels CSS ein natives Look & Feel der jeweiligen Oberflächen zu erstellen. Je nach Plattform bekommen Buttons, Tabs usw. das typische Aussehen der jeweiligen nativen Elemente. Dabei können auch eigene Elemente so dargestellt werden, dass sie unter iOS ein anderes Aussehen besitzen als unter Android. Seit der zweiten Version von Ionic wird Angular (ab Version 2) als JavaScript-Framework verwendet, was die Verwendung von vorgefertigten Komponenten und die generelle Struktur der App vereinfacht. Intern baut Ionic auf Cordova auf und profitiert somit von den stetigen Verbesserungen des App-Containers und der Plugins.

Letztlich bleibt die Frage nach den nativen APIs. Weiterhin können keine native APIs direkt angesteuert werden. Dies muss weiterhin über ein Cordova-Plugin geschehen, jedoch sind diese dank der Open-Source-Community deutlich stabiler und vielseitiger geworden. Auch Ionic stellt für ziemlich alle nativen APIs Plugins zur Verwendung bereit, die einfach in die App einzubinden sind.

 

Die Zukunft

Hybride Apps wird es wohl weiterhin geben. Dank der steigenden Beliebtheit von JavaScript, steigt auch die Anzahl an Frameworks und Bibliotheken, die für Problemlösungen verwendet werden können. Mit Capacitor, dem neusten Projekt vom Ionic-Team, wurde die Idee von Cordova neu interpretiert und umgesetzt, um eine moderne Alternative zu Cordova zu bieten. Auch abseits des hybriden Wegs versuchen Entwicklerteams neue Lösungen zu finden. Frameworks wie beispielsweise NativeScript und React Native zum Beispiel ermöglichen auf einer etwas anderen Art mobile Apps mit JavaScript zu programmieren und gehen einen nativeren Weg: Statt die Anwendung in einem App-Container zu verwalten wird der Code mittels einer Bridge interpretiert. Während die Views nativ gerendert werden. Mehr dazu dann aber in einem zukünftigen Artikel.

 

Thanks to Christian Müller. 

 

 

 

Ähnliche Artikel

Developer Content
12. Oktober 2023 4 Min. Lesezeit
Das Rad nicht neu erfinden - IT Frameworks einsetzen lohnt sich
Weiterlesen
Developer Content
26. Januar 2022 4 Min. Lesezeit
Was Kuchenbacken und Softwareentwicklung gemeinsam haben
Weiterlesen
Developer Content
14. August 2020 6 Min. Lesezeit
Einstieg in die testgetriebene Entwicklung
Weiterlesen
Developer Content
1. April 2020 7 Min. Lesezeit
Code Review bei BRICKMAKERS
Weiterlesen
Developer Content
6. März 2020 2 Min. Lesezeit
Kovarianz und Kontravarianz von Unit-Tests
Weiterlesen
Developer Content
11. Dezember 2019 3 Min. Lesezeit
Cloud Architekturen im Überblick
Weiterlesen
Pfeil nach links
Pfeil nach rechts