Native und PWA: Entscheidungen, keine Herausforderer!

Es ist schwer zu sagen, wo genau die Kluft zwischen „nativ“ und „Web“ wirklich begann. Ich habe das Gefühl, dass es eines dieser Dinge ist, die seit den frühen Tagen von Flash direkt unter der Oberfläche brodelten, nur um in jüngerer Zeit mit dem Aufstieg mobiler Plattformen auszubrechen. Unabhängig davon haben sich die Entwickler über diese „große Kluft“ hinweg gekämpft und sich gegenseitig beleidigt, um ihre eigene Seite zu stärken.

Ich habe kein Interesse an diesem Kampf. Sicher, ich bin ein „Web-Typ“, aber das heißt nicht, dass ich den Reiz der nativen Entwicklung nicht sehe; Ich bin auch Softwareentwickler. Vor allem aber bin ich Pragmatiker. Mir ist klar, dass jedes Projekt anders ist und dass unsere Herangehensweise an jedes Projekt auf die Bedürfnisse und Ziele des Projekts zugeschnitten sein sollte.

Da Progressive Web Apps (PWAs) in den Bereich der nativen Entwicklung vordringen, dachte ich, dass dies ein guter Zeitpunkt wäre, einen Schritt zurückzutreten und eine Bestandsaufnahme dieser beiden Ansätze zur Entwicklung von Produkten vorzunehmen. Ich hoffe, dass wir alle mit der Fähigkeit nach Hause gehen werden, die Stärken jedes Ansatzes klar zu erkennen, in der Hoffnung, die richtige Lösung für die von uns entwickelten Produkte zu finden.

Ein Schnellfeuer-Vergleich

Von Anfang an wurden webbasierte Erfahrungen mit allem verglichen, von Desktop-Software (den ursprünglichen „nativen Apps“) über interaktive CD-ROMs bis hin zu Flash und seit kurzem auch mobilen Apps. Obwohl das Web bei zahlreichen Gelegenheiten für tot erklärt wurde, hat es sich gehalten. In vielen Fällen hat es sogar seine angeblichen Killer überlebt (RIP Flash).

Eine der größten Stärken des Webs in dieser Hinsicht ist seine Anpassungsfähigkeit. Es konnte so ziemlich überall hin mitgenommen werden, wo es eine Internetverbindung gibt, und gewinnt ständig neue Fähigkeiten hinzu. Alle Programmiersprachen entwickeln sich weiter, daher ist es nicht unerwartet, aber im Laufe der Zeit haben die wachsenden Grenzen des Internets immer weiter in das Revier traditioneller Software vorgedrungen.

Ein Bereich, in dem das Web in der Vergangenheit zu kurz kam, war jedoch der Bereich der Leistung. Installierte Software kann sich auf eine Weise mit dem zugrunde liegenden Betriebssystem verbinden, wie es das Web einfach nicht kann. Sie sind in der Lingua Franca ihres Gastgebers geschrieben, mit direktem Zugriff auf die Hardware oder „näher am Metall“, wie wir oft sagen. Das Web, das fast immer eine oder mehrere Abstraktionsschichten darüber betreibt, hat es schwer, in Sachen Performance zu konkurrieren. Während sich die Leistungslücke im Laufe der Zeit verringert hat, wird nativer Code wahrscheinlich weiterhin schneller ausgeführt als Webcode, zumindest bis das Web in der Lage ist, Signale direkt von den Pins der Hardware zu interpretieren.

Hand in Hand mit dem Leistungsvorteil hat die native Entwicklung einen viel größeren (und früheren) Zugriff auf Gerätefunktionen wie NFC, Bluetooth, Näherungs- und Umgebungslichtsensoren und mehr. Auch das Web erhält stetig Zugriff auf diese Funktionen, wird aber immer hinter den nativen APIs zurückbleiben, da die nativen APIs entwickelt werden müssen, bevor das Web sie nutzen kann, und die Standardisierung in der gesamten Browserlandschaft Zeit braucht.

Darüber hinaus kann sich nativer Code in Funktionen auf Betriebssystemebene wie Adressbuch und Kalender einklinken. Push-Benachrichtigungen waren ein weiteres großes Problem, aber Service Workers ermöglichen es dem Internet jetzt, diese Funktion ebenfalls zu nutzen. Die Zahlungsabwicklung hat sich in letzter Zeit im Internet ebenfalls verbessert. Vielleicht kommen Adressbuch und Kalenderzugriff irgendwann auch ins Web.

Um kurz auf Service Workers zurückzukommen, hat diese jüngste Erweiterung der Toolbox von Webentwicklern noch eine Reihe weiterer Tricks auf Lager. Erstens bietet es ein viel robusteres Caching-System als das Web zuvor mit AppCache hatte. Sie können Service Worker verwenden, um Offline-Anfragen zu verwalten, bestimmte Ressourcen zwischenzuspeichern, Daten mit einem Remote-Server zu synchronisieren, wenn der Benutzer die Website nicht einmal geöffnet hat, und vieles mehr. Vielleicht mehr als jede andere einzelne Technologie haben Service Worker dem Web ermöglicht, eine App-ähnlichere Erfahrung zu bieten.

Service Worker sind einer der drei technischen Dreh- und Angelpunkte von PWAs. Ein weiteres ist das Web App Manifest. Auch wenn es ein wenig langweilig klingen mag, ist ein Web App Manifest tatsächlich ein unglaublich leistungsfähiges Tool, da es einer Website ermöglicht, sich selbst als App zu bewerben. Dieses relativ unkomplizierte JSON-Dateiformat bietet eine Fülle von Informationen über die beschriebene Website und ermöglicht es PWA-fähigen Browsern und Betriebssystemen, die Website so zu installieren, als wäre es native Software.

Einige App-Stores beginnen sogar damit, PWAs zu indizieren, indem sie ihr Manifest verwenden, um die zugehörigen Einträge zu füllen. Aus Benutzersicht unterscheiden sich PWAs in App Stores nicht von den sie umgebenden nativen Apps. Sie sind installierbar, deinstallierbar und können ihre Einstellungen sogar dem App-Verwaltungstool des zugrunde liegenden Betriebssystems zur Verfügung stellen. Es ist auch erwähnenswert, dass PWAs keinen Benutzer benötigen, um sie explizit zu installieren, um sie zu verwenden, da sie im Internet leben.

Sowohl online als auch offline zu sein bedeutet auch, dass PWAs immer auf dem neuesten Stand sind. Benutzer müssen nichts Neues aktiv herunterladen, um auf neue Funktionen zuzugreifen. Und selbst wenn neue Inhalte und Funktionen eingeführt werden, ist es höchst unwahrscheinlich, dass ein Benutzer Ihre gesamte PWA erneut herunterladen muss, wie dies bei den meisten nativen Apps der Fall wäre. Wenn überhaupt, erhalten sie möglicherweise ein paar neue Assets und etwas neues HTML, und es würde ziemlich augenblicklich passieren, kein App Store erforderlich. Natürlich haben Sie immer noch die Entdeckungs- und Vertriebsoption, die von App Stores bereitgestellt wird, also ist es wirklich das Beste aus beiden Welten.

In App-Stores zu sein, stellt PWAs in Bezug auf Entdeckung, Verteilung und Monetarisierung auf die gleiche Stufe wie native Apps. Tatsächlich kann es sogar das Web über natives springen, da PWAs auch über Suchmaschinen auffindbar sind und unendlich viel mehr gemeinsam genutzt werden können als Apps, da sie unter einer URL existieren. Wenn sie gut gebaut sind, sind PWAs auch über Browser, Plattformen und Geräte hinweg interoperabel. PWAs funktionieren sogar in Browsern, die Features wie Service Workers nicht unterstützen, da PWA-Features progressive Verbesserungen sind.

Das Web bietet auch eine sehr ausgereifte Unterstützung für Barrierefreiheit, wodurch es relativ einfach ist, sicherzustellen, dass Ihre Projekte von der größtmöglichen Anzahl von Benutzern verwendet werden können. Komplexe Schnittstellen erfordern etwas mehr Sorgfalt bei der Programmierung, aber die Barrierefreiheitsvorteile, die semantisches HTML bietet, handhaben grundlegende Barrierefreiheit mit Souveränität – insbesondere, wenn es um textlastige, informative oder einfache formularbasierte Produkte geht. Im Gegensatz dazu müssen Sie Barrierefreiheits-APIs fast immer kennen und in Ihren nativen Code integrieren.

Zum Thema Entwicklung, ich glaube nicht, dass es einen klaren Gewinner gibt, wenn es um Entwicklungserfahrung geht. Jede Sprache hat ihre Fans, und das gilt auch für Entwicklertools. Sie mögen, was Sie mögen, und Sie sind in der Regel effizienter mit den Tools und Sprachen, die Sie kennen und für die Sie sich begeistern. Weder das Web noch die native Entwicklung haben hier einen deutlichen Vorteil.

Die native Entwicklung glänzt jedoch, wenn es darum geht, ein konsistentes Qualitätsniveau für Benutzeroberflächen sicherzustellen, die mit ihren SDKs (Software Development Kits) erstellt wurden. Die meisten nativen SDKs bieten Tools zum Testen von Leistung, Design, Funktionalität und mehr. Dazu gehören auch Boilerplate-Code, Designsysteme und andere Tools, die dazu beitragen, die Messlatte nativer Softwareangebote höher zu legen. Sicher, es gibt ähnliche Tools für das Web, aber sie sind über das Web verstreut und nicht universell in allen verschiedenen Entwicklungsumgebungen, die Leute zum Erstellen von Websites verwenden. Es gibt keine einzelne Einheit, die qualitativ hochwertige Weberlebnisse definiert und die Tools bereitstellt, um sie zu erstellen (obwohl viele es versucht haben).

Wenn es darum geht, die Entwicklung eines Produkts mit Personal zu besetzen, ist es definitiv einfacher, Leute einzustellen, die wissen, wie man für das Web entwickelt. Während ich tippe, stuft der Programming Language Index derzeit JavaScript als die beliebteste Sprache ein, direkt dahinter Java. C# liegt auf Platz 5, HTML auf Platz 7, CSS auf Platz 9 und Swift auf Platz 15. Dieser Index verweist auf Stack Overflow-Tags mit Zeilen, die in öffentlichen Repositories auf GitHub geändert wurden, also sollte er mit einem Körnchen Salz genommen werden, aber er liefert einen ziemlich klaren Hinweis darauf, dass viele Leute Webtechnologien kennen (und verwenden). Auf der anderen Seite kann es oft schwierig sein, talentierte native Entwickler zu finden und einzustellen, da es weniger von ihnen gibt und sie sehr gefragt sind.

Knappe Talente bedeuten, dass Sie am Ende wahrscheinlich mehr für die native Entwicklung bezahlen werden. Natürlich ist jedes Projekt anders und hat unterschiedliche Merkmale und Anforderungen, aber es kann anschaulich sein, die durchschnittlichen Entwicklungskosten als Vergleich zu betrachten. Comentum schlägt vor, dass die Erstellung einer mittelgroßen Web-App zwischen 10.000 und 150.000 US-Dollar kostet. Auf der nativen Seite schätzt Appster, dass mobile App-Projekte mittlerer Größe zwischen 110.000 und 305.000 US-Dollar für die Erstellung kosten. Es ist wahrscheinlich davon auszugehen, dass die Entwicklung nativer Projekte etwa doppelt so viel kostet wie die Entwicklung eines Webprojekts. Und das pro Plattform. Auch die Entwicklung nativer Apps dauert in der Regel länger.

Es ist erwähnenswert, dass es Möglichkeiten gibt, native Software mithilfe von Webtechnologien zu erstellen, ohne eine PWA zu erstellen. Mit Frameworks wie React Native, PhoneGap, Ionic und Appcelerator Titanium können Sie nativen Code aus HTML, CSS und JavaScript generieren. Die Verwendung eines dieser Tools könnte Ihre Personal- und Entwicklungskosten im Vergleich zur Einstellung eines Teams nativer Entwickler senken, aber in Bezug auf den Zugriff auf Gerätefunktionen ist Ihr Projekt auf die Funktionen beschränkt, die das Framework implementiert hat. Planen Sie entsprechend.

Sobald die App entwickelt ist, müssen Sie auch die laufenden Wartungskosten dieser App oder Apps berücksichtigen. Als Antwort auf eine von Clutch durchgeführte Umfrage empfiehlt Dom & Tom, im ersten Jahr 50 % des Anfangspreises des Produkts einzuplanen, im zweiten Jahr 25 % und für jedes weitere Jahr zwischen 15 und 25 %.

Sobald Sie ein gutes Verständnis dafür haben, wie Web- und native Entwicklung verglichen und kontrastiert werden, können Sie damit beginnen, zu beurteilen, welche Stärken und Schwächen für Ihr Projekt relevant sind. Sie müssen wahrscheinlich einige Kompromisse eingehen, und das ist zu erwarten. Es gibt keine One-size-fits-all-Lösung. Und wenn es so wäre, würde es niemandem gut passen.

Lassen Sie uns ein paar hypothetische Projekte durchgehen, um die Unterschiede zwischen der Entwicklung für native und PWA deutlicher hervorzuheben.

Projekt Nr. 1: Eine vorhandene native App

Nehmen wir an, Sie haben bereits den Prozess der Erstellung einer nativen App durchlaufen. Wenn alles gut läuft, gibt es keinen Grund, den Kurs zu ändern. Werfen Sie nicht Ihre gesamte bestehende Arbeit weg, um zu einer PWA zu wechseln, es sei denn, Sie haben einen wirklich guten Grund dafür. Ich kann mir nur ein Szenario vorstellen, das einen Wechsel zu PWA rechtfertigen könnte: Unterstützung für ein neues Betriebssystem in den Mix zu bringen. Und selbst dann macht es nur dann wirklich Sinn, wenn die Anforderungen Ihrer App allein über das Web erfüllt werden können.

Wenn Sie einem Produkt Unterstützung für eine neue Plattform hinzufügen, bietet dies die perfekte Gelegenheit, die Anforderungen und Ziele des Projekts im Hinblick auf die Kosten für die Erfüllung dieser Anforderungen zu bewerten. Wenn das Web der Aufgabe nicht gewachsen ist, bleiben Sie bei nativen. Wenn dies jedoch der Fall ist, halten Sie inne und bedenken Sie Folgendes: Das Hinzufügen von Unterstützung für die neue Plattform mithilfe einer PWA würde es Ihnen ermöglichen, später weitere Plattformen (einschließlich des Webs) zu unterstützen, und könnte Ihnen sogar ermöglichen, Ihre vorhandene native Anwendung zu ersetzen, sobald die PWA dies getan hat gründlich getestet worden.

Wenn es Ihnen undenkbar erscheint, eine vorhandene native App durch eine PWA zu ersetzen, bedenken Sie Folgendes: Starbucks und Twitter untersuchen diese Idee bereits.

Wenn es bestimmte Gründe gibt, warum Sie Ihre Apps nativ halten müssen, kann es sich dennoch lohnen, bestimmte App-Funktionen ins Web auszulagern. Vor ein paar Jahren arbeitete ich an einem Projekt für ein großes Finanzdienstleistungsunternehmen, und sie entschieden sich dafür, den Anmeldefluss für ihre nativen Apps ins Web zu verlagern, damit sie Sicherheitsfunktionen schneller einführen können als der typische App Store Genehmigungsverfahren ermöglichten es ihnen, zu erreichen. Vielleicht hat Ihr Projekt ähnliche Anforderungen, die das Web mit Ihrer nativen App erfüllen könnte.

Projekt Nr. 2: Eine bestehende plattformübergreifende App

Wenn Sie eine vorhandene App haben, die plattformübergreifend funktioniert, geben Sie wahrscheinlich viel Geld für die laufende Entwicklung und Wartung dieser App aus. Sie werden wahrscheinlich auch einige Unterschiede in den In-App-Funktionen feststellen, da jede native Plattform in der Regel ihren eigenen Entwicklungszeitplan hat. Die App des Einzelhändlers Target beispielsweise ermöglicht es den Nutzern derzeit, eine Einkaufsliste auf iOS zu verwalten, aber die Android-Version hat diese Funktion nicht. In vielerlei Hinsicht ähnelt es der Divergenz, die wir manchmal zwischen der „Desktop“- und der „mobilen“ Version einer Website sehen.

Wenn das Web bereits Teil Ihres plattformübergreifenden Mixes ist, bietet es eine gute Gelegenheit, Ihre dortigen Investitionen zu verdoppeln und in Betracht zu ziehen, Ihre nativen Apps durch PWAs zu ersetzen. Tools wie Sonar und Lighthouse können Ihnen Aufschluss darüber geben, wie gut Ihre bestehende Website auf die PWA-ifizierung vorbereitet ist, und sie können Ihnen auch sagen, woran Sie arbeiten müssen. Von dort aus ist es relativ einfach, Ihre Website in eine PWA zu verwandeln. Es gibt sogar kostenlose Tools, mit denen Sie Ihre Website in wenigen Minuten auf eine PWA aktualisieren können. Wenn dies nicht der Fall ist, gibt es wirklich keinen großen Anreiz, diesen Schritt zu tun, es sei denn, die Funktionsunterschiede zwischen den Plattformen werden wirklich ungeheuerlich oder Sie erwägen, eine weitere native Plattform (oder das Web) in den Mix aufzunehmen.

Projekt Nr. 3: Ein neues plattformübergreifendes Produkt

Wenn Sie ein neues Projekt starten, das auf mehr als eine Plattform abzielt, sollte es auf jeden Fall auf dem Tisch liegen, es an einem Ort als PWA zu erstellen und zu pflegen. Abhängig von Ihrem Budget und Ihrem Personal wird es Ihr Budget wahrscheinlich am weitesten strecken. Wenn Ihr Produkt jedoch eine direkte Verbindung zur Hardware oder zum zugrunde liegenden Betriebssystem erfordert, müssen Sie möglicherweise immer noch nativ werden. Aber bevor Sie diesen Weg einschlagen, erstellen Sie eine Liste aller Ihrer Anforderungen und überprüfen Sie dann, was das Web leisten kann (und was nicht). Achten Sie darauf, auch in mehr als einem Browser nach Unterstützung zu suchen.

Projekt Nr. 4: Ein neues hyperfokussiertes Produkt

Wenn Sie ein neues Produkt entwickeln und ein Teil des gesamten Zwecks dieses Produkts seine tiefe Verbindung zu einer bestimmten Plattform ist, bauen Sie auf jeden Fall für diese Plattform. Wenn Ihr Produkt beispielsweise auf der Messages-Plattform von Apple oder der Integration mit HomeKit basiert, erstellen Sie es auf jeden Fall für iOS und/oder macOS in Swift. Wenn Ihr Produkt die Benutzeranforderungen am besten über ein Widget erfüllt oder Sie einen benutzerdefinierten Launcher erstellen, erstellen Sie am besten Android und müssen Java verwenden.

Allerdings sind nicht alle einheimischen Merkmale Walled Gardens. Während Alexa von Amazon, Siri von Apple und Google Assistant alle einen nativen Code (oder eine JSON-API) benötigen, um sich in Ihre App zu integrieren, wird Cortana von Microsoft Ihre PWA interessanterweise nur mit einer XML-Datei sprachaktivieren, die aus dem head Ihres HTML-Codes verknüpft ist. Vielleicht werden andere ihrem Beispiel folgen.

PWA oder nativ? Es ist deine Entscheidung

Sowohl das Web als auch native haben viel zu bieten. Wenn Sie mich fragen würden, was besser ist, würde ich einfach antworten: „Es kommt darauf an“, weil es so ist. Ich bin nicht ausweichend oder unverbindlich; Welche Lösung für Ihr Projekt die richtige ist, hängt ganz von den spezifischen Anforderungen Ihres Projekts ab. Es erfordert, dass Sie berücksichtigen, was Sie bauen, die Zusammensetzung des bestehenden Teams, das mit dem Bau beauftragt ist, oder das Team, das Sie dafür einstellen müssen, und das Budget, mit dem Sie arbeiten müssen. In vielen Fällen bietet das Internet wahrscheinlich alles, was Sie zum Erreichen der Ziele Ihres Projekts benötigen, aber es gibt immer Ausnahmen. Wenn Sie die Möglichkeiten erkunden möchten, die das Web bietet, habe ich am Ende dieses Artikels einige Ressourcen eingefügt.

Das Wichtigste, was Sie tun können, wenn Sie verschiedene Ansätze zur Softwareentwicklung – oder verschiedene Frameworks, Bibliotheken, Sprachen, Designsysteme usw. – abwägen, ist, Ihre Optionen in Bezug auf das jeweilige Projekt zu berücksichtigen. Recherchieren Sie und wägen Sie Ihre Optionen ab. Und lassen Sie sich nicht von cleverem Marketing, sexy Demos oder tollwütigen Fanboys auf die eine oder andere Weise beeinflussen. Darunter auch diese.

PWA-bezogene Ressourcen

• PWA-Builder
  Ein 3-Schritte-Tool zur Erstellung von Websites zu PWAs mit hilfreichen Empfehlungen und Rezepten. Außerdem können Sie Ihre PWA in installierbare native Apps für Windows, Android und iOS umwandeln.
• Eine Progressive Roadmap für Ihre Progressive Web App
  Jason Grigsby darüber, wie sein Team im Laufe mehrerer Monate damit begann, Aspekte von PWAs in seine Website zu integrieren, und demonstrierte schön, wie die verschiedenen Funktionen nach und nach hinzugefügt werden können.
• Ja, dieses Webprojekt sollte eine PWA sein
  Ein Überblick über die UX-Chancen (und -Risiken) von PWAs, geschrieben von Ihnen.
• Progressive Web-Apps auf MDN
  Ein Knotenpunkt für alle technischen Details, die Sie darüber wissen müssen, was eine hochwertige PWA auszeichnet.
• Was das Web heute leisten kann
  Werfen Sie einen Blick auf die APIs, die Ihr Gerät, Betriebssystem und Browser unterstützen. Was Sie finden, könnte Sie überraschen.
• Kann ich benutzen
  Die endgültige Datenbank darüber, welche APIs und Funktionen in jedem gängigen Browser verfügbar sind und wie diese Unterstützung im Vergleich zu den tatsächlich verwendeten Browsern abschneidet. Es kann Ihnen auch einen hervorragenden Blick in die Vergangenheit geben, um zu sehen, wie abwärtskompatibel bestimmte Funktionen sind.