Electron und Cordova vs. PWA – wann, was, wie und warum?

Cross-Platform-Entwickler, die auf Webtechniken setzen, haben die Qual der Wahl: Verpackt man Web-Apps auf altbewährte Weise mit Apache Cordova und GitHub Electron? Oder greift man lieber auf Progressive Web Apps zurück, bei denen das Leben der Anwendung im Browser beginnt?

In Pocket speichern vorlesen Druckansicht 16 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Christian Liebel
Inhaltsverzeichnis

Cross-Platform-Entwickler, die auf Webtechniken setzen, haben die Qual der Wahl: Verpackt man Web-Apps auf altbewährte Weise mit Apache Cordova und GitHub Electron? Oder greift man lieber auf Progressive Web Apps zurück, bei denen das Leben der Anwendung im Browser beginnt?

Optisch unterscheiden sich beide Methoden kaum: Am Ende läuft die eigene Web-App auf Desktopsystemen in einem eigenen Fenster, auf Mobilgeräten vollflächig – wie alle anderen Apps auch. Unterschiede gibt es jedoch in der Art der Verteilung und im Funktionsumfang.

Webtechnologie sprengt Plattformgrenzen

Bei Cordova und Electron wird eine Webanwendung in einem nativen Anwendungsrahmen verpackt. Über ihn lassen sich sämtliche Funktionen und APIs aufrufen, die die jeweilige Plattform zur Verfügung stellt. Insgesamt stehen diese Anwendungen ihren nativen Gegenstücken in nichts nach. Daher können sie auch über alle Vertriebswege verteilt werden, typischerweise App-Stores im mobilen Umfeld oder als Executable für den Desktop.

Problematisch bei diesem Ansatz ist aber, dass nicht nur die Anwendung selbst zu warten ist, sondern auch der Container. Bei Electron sind neben der eigentlichen App darüber hinaus noch Node.js und Chromium Teil des Anwendungsbündels, die regelmäßig aktualisiert werden sollten. Im Falle von Cordova ist festzustellen, dass die bereitgestellten Plug-ins, die Zugriff auf native Funktionen erlauben, zunehmend altern und die Weiterentwicklung oftmals an einer überschaubaren Anzahl an Community-Mitgliedern hängt.

Progressive Web Apps kommen komplett ohne diesen Wrapper aus. Stattdessen beginnt das Leben der Anwendung im Browser, von dort kann sie auf dem jeweiligen Gerät installiert werden. Somit fallen auch keine Kosten für App-Stores an, Verkäufe oder Abogebühren sind ebenfalls nicht mehr zwingend mit dem Plattformanbieter zu teilen. Das heißt aber nicht, dass sich diese Anwendungen nicht später doch wieder in einen Store einstellen lassen. Der Microsoft Store und Google Play nehmen so auch Progressive Web Apps auf.

Allerdings können Progressive Web Apps nicht auf sämtliche nativen Schnittstellen zugreifen, sondern nur auf diejenigen, für die es auch eine Webschnittstelle gibt. Das Web hat in den vergangenen Jahren viele APIs mit nativer Power erhalten, etwa Browserdatenbanken, Zugriff auf Geolocation, Mikrofon und Kamera, doch es bleibt noch ein gewisser Versatz zum kompletten nativen Funktionsumfang. Dank Initiativen wie Project Fugu schwindet dieser Abstand aber zusehends.

Webanwendungen sollten zunächst immer mit dem Ziel entwickelt werden, eine Progressive Web App zu sein. Niemand hindert Entwickler später daran, diese doch noch in einem nativen Anwendungscontainer zu verpacken. Wer zu sehr auf native APIs baut, kann seine Anwendung umgekehrt nicht so einfach als PWA bereitstellen. Nur dann, wenn Entwickler auf eine kritische Funktion stoßen, für die es keine Webschnittstelle gibt oder zwingend ein Executable oder eine Präsenz im Apple App Store gebraucht wird, sollten sie ergänzend oder alternativ auf Wrapper-Ansätze wie Cordova und Electron zurückgreifen.

Ausführlich beleuchten Christian Liebel und Thorsten Hans von Thinktecture dieses Thema am 27. Februar 2020 im Rahmen der BASTA! Spring in Frankfurt. ()