Köpfe für Kopflose: Die neuen Frontend-Technologien im Überblick

Gepostet von

In den vergangenen Monaten haben wir im Blog und in den Podcasts immer mal wieder über neue, mobile Frontends gesprochen und welche Rolle dabei Single Page Apps und Progressive Web Apps spielen (ShopTechTalks #47: Wenn die Frontend-Freaks kommen). Aber welche Technologien und Anbieter gibt es mittlerweile da draußen, wie werden sie eingesetzt und welche Standards haben sich mittlerweile etabliert?

Terminologie: SPAs & PWAs

Zunächst sollten wir uns kurz die Terminologie anschauen, um gemeinsam den gleichen Ausgangspunkt zu haben. Wenn man sich anschaut, wie die meisten Websites aufgebaut sind, stößt man schnell auf eine mehr oder weniger anspruchsvolle Kombination von HTML, CSS und JavaScript. Diese Seiten folgen seit jeher dem Standard von Multiple Page Apps (MPAs), was bedeutet: Browser senden Anfragen an Server, die Informationen zur Verfügung stellen und Code sowie Mediendaten zurücksenden. Wird eine neue Seite aufgerufen, weil sich der Benutzer im E-Commerce-Kontext beispielsweise von der Kategorieübersichtsseite auf eine Produktdetailseite bewegt, geht das gleiche Spiel von vorne los. Viele Seiten, viele Roundtrips der Daten, die klassische Welt des Internet.

Mit dem Aufkommen von Smartphones und dem Erfolg von Apps hat sich die Welt aber an andere, schnellere und sexy-ere Benutzeroberflächen gewöhnt. Anstatt wie bei einer klassischen Website zu warten, bis sich alles in Gänze im Browser aufgebaut hat, ist die Reaktion einer Smartphone-App nicht zeitverzögert. Verständlich, dass Entwickler diese Erfahrung von der App- auf die Internetwelt übertragen wollen. Enter Single Page Apps (SPAs). Die gibt es schon seit einigen Jahren und emulieren im Grunde das Verhalten nativer Apps. Über den mobilen Brower wird anfangs eine Art Anwendungshülle oder -skelett heruntergeladen, das dann bei der Benutzung mit den entsprechenden Daten gefüllt wird. Sprich, der Nutzer bleibt auf einer Seite und bewegt sich fluffig durch eine App-artige Website, während im Hintergrund fleißig und in Echtzeit die Rohdaten übertragen werden, die dann innerhalb der App-Hülle gerendered werden. Frameworks wie Angular.js oder React.js, die ich weiter unten genauer beschreibe, erlauben diese Art von Kommunikation sind die Grundlage von SPAs. In freier Wildbahn kann man sich die Resultate etwa bei Facebook, LinkedIn oder Gmail ansehen.

Funktionsweise von Single Page Apps (SPAs)
Funktionsweise von Single Page Apps (SPAs)

Aber irgendwie geht ja alles noch immer noch besser. Google bzw. sein Chrome-Team schickt mit Progressive Web Apps (PWAs) ein neues Architekturprinzip für mobile Anwendungen ins Rennen, das die beschriebenen SPAs um wichtige Funktionen erweitert. Durch sogenannte Service-Worker können diese Apps etwa auf den lokalen Speicher des jeweiligen Geräts zugreifen. So werden PWAs auch offline nutzbar, was bislang nur nativen Apps vorbehalten war. Auch das Versenden von Push-Notifications wird ermöglicht, ebenso wie das Hinzufügen des App-Icons zum Homescreen. Wir haben es also im Prinzip mit einer Mischung aus nativer App und Web App zu tun, bei der das beste aus beiden Welten kombiniert wird. Es gibt allerdings nicht nur Vorteile – zum Schluss des Artikels gehe ich noch im Detail darauf ein, welche Herausforderungen PWAs mit sich bringen.

Das soll als kleiner definitorischer Exkurs ausreichen, wer sich tiefer in die Grundlagen einlesen möchte, dem seien diese Links ans Herz gelegt:

Und wer sich PWAs im echten Leben ansehen möchte, findet auf pwa.bar viel Anschauungsmaterial von Google Maps über NASA bis hin zu Tinder und der Financial Times.

Frameworks

Kommen wir nun konkret zu den Technologien. Es handelt sich um JavaScript-basierte Frameworks, die üblicherweise unter einer OpenSource-Lizenz stehen und ihren Ursprung meist bei einem großen Tech-Anbieter haben. Ich bin kein JS-Experte, daher kann ich nicht im Detail beschreiben, welche Vor- und Nachteile die einzelnen Frameworks haben bzw. deren Güte bewerten. Gefühlt sind die Entscheidungskriterien für die eine oder andere Technologie eine bunte Mischung aus Out-of-the-Box-Features (hier eine detaillierte technische Vergleichstabelle), persönlicher Präferenz, den damit bereits realisierten Projekten bzw. Referenzen und die Einschätzung der Unternehmen, die diese Frameworks vorantreiben. Egal wie man sich entscheidet, bei allen handelt es sich um leistungsfähige und in der Praxis erprobte Technologien. Stellvertretend für die vielen, die sich mittlerweile entwickelt haben, schauen wir uns Angular, React und Vue jetzt etwas genauer an.

Angular

Das Framework Angular (in der ersten Version unter den Namen AngularJS bekannt, das sich im Long Term Support befindet) wurde ursprünglich von Google entwickelt und erstmals 2009 veröffentlicht. Mittlerweile steht das Framework unter der MIT-Lizenz und wird von Google und der OpenSource-Community weiterentwickelt. Zu den bekanntesten Angular-Projekten gehören Paypal, Youtube und The Guardian.

React

Wie Angular hat auch React seinen Ursprung in einem großen amerikanischen Tech-Konzern. Bei Facebook war das Framework zuerst im Einsatz und wird dort seit 2011 für den Newsfeed benutzt. Seit 2013 ist es unter MIT-Lizenz erhältlich und wird von Facebook, Instagram und der Community weiterentwickelt. Unternehmen wie AirBnB und Netflix setzen bei der Entwicklung Ihrer SPAs auf React.

Interessant zu erwähnen ist in diesem Kontext noch React Native, wie der Name schon vermuten lässt ein Entwicklungsframework für native Apps. Der Clou: die Funktionalität und das Design seiner App gestaltet man exakt wie bei React selbst mittels JavaScript, kann dann aber auf Knopfdruck native Apps für iOS oder Android exportieren.

Vue.js

Last but not least sei Vue.js erwähnt. Dieses Framerwork wurde von Evan You entwickelt, der vormals bei Google mit Angular gearbeitet hatte und ein leichtgewichtiges JS-Framework bauen wollte. Seine Technologie ist seit 2014 auf dem Markt und wird ebenfalls unter einer MIT-Lizenz von der Community weiterentwickelt.

Umfrage-Ergebnisse State of JS 2018

Weitere Frameworks wie Ember, Polymer etc. findet Ihr unter 10 Best JavaScript Frameworks to Use in 2019.

Produkte & kommerzielle Anbieter

Inbesondere als Reaktion auf den Trend hin zu Headless-Systemen bieten vergleichsweise junge Frontend-as-a-Service-Unternehmen neue Produkte auf Basis dieser „rohen“ JavaScript-Frameworks an, indem sie beispielsweise gleich Hosting und CDN für individuelle Frontends sowie Editier- und Testmöglichkeiten für Nichtprogrammierer bereitstellen. Außerdem stehen üblicherweise eine API sowie eine Reihe von Standardintegrationen zur Verfügung, um diese Frontendgeneratoren mit E-Commerce und CMS-Daten etwa von commercetools, Contentful oder Contentstack zu versorgen.

FRONTASTIC

Der bekannteste FaaS-Anbieter dürfte derzeit hierzulande FRONTASTIC sein – nicht zuletzt dadurch, dass wir das Team rund um Thomas Gottheil und Henning Emmrich schon mehrfach im Blog erwähnt und mit ihnen auch einen Podcast aufgenommen haben (ShopTechTalks #28: Mobile Frontends mit FRONTASTIC). Mithilfe ihrer Cloud-Plattform und einem gehosteten React lassen sich vereinfacht gesagt vorgegebene und eigene Komponenten (genannt Tastics) zu einer individuellen PWA kombinieren. Live kann man sich das bereits bei Apollo Optik und Chronext ansehen (hier die Pressemeldung dazu).

Mobify

Mobify wurde bereits 2007 als Anbieter von mobilen Dienstleistungen in Kanada gegründet. Erst seit Kurzem fokussiert man sich auf die Bereitstellung einer Infrastruktur, die ähnlich wie bei FRONTASTIC den Aufbau und die Pflege einer PWA erlaubt. Der Anbieter ist derzeit vor allem in Nordamerika und England aktiv, zu den bekanntesten Kunden gehören beispielsweise Debenhams oder Lancôme. Über die Dokumentation und das Github-Repo kann man sich näher mit der zugrundeliegenden Technologie beschäftigen und erfährt unter anderem, dass Mobify ebenfalls React zugrundelegt.

Vue Storefront

Bei Vue Storefront handelt es sich um eine OpenSource-Initiative. Interessierte Entwickler haben eine E-Commerce-PWA auf Basis von Vue.js erstellt, die an diverse Shopsysteme wie Magento, SAP Hybris und Shopify angedockt werden kann. Außerdem im Angebot ist eine kommerzielle Variante namens Storefront-Cloud, die Händlern das Hosting der eigenen PWA abnimmt. Getrieben werden diese Projekte von Divante, einem Systemintegrator aus Breslau, der unter anderem Projekte für Staples und Zadig&Voltaire auf Basis der Cloud-Lösung umgesetzt hat.

Indizierung & Archivierung

Diese Übersicht wäre nicht komplett, wenn wir nicht kurz darauf eingehen, welche sonstige Auswirkungen diese Art von mobilen Frontends noch haben. Auch wenn ich weder Fan noch Experte in diesem Bereich bin, es geht um die Auffindbarkeit in Suchmaschinen und das darum mit mehr oder weniger Ernst verfolgte SEO. Immerhin – so sollte mittlerweile klar geworden sein – hat man es bei SPAs und PWAs nicht mit guten, alten HTML-/CSS-Konstruktionen zu tun, die einfach von den diversen Crawlern indiziert werden können, sondern mit komplexen JavaScript-Gebilden und dynamisch geladenen Inhalten. Oder ums es plastisch zu formulieren: Welche Seiten soll den Google bitteschön indizieren, wenn es per Definition bei SPAs nur eine Seite gibt? Ich habe dazu etwas recherchiert und folgende interessante Grafik bei Moz gefunden:

Wie werden SPAs von Suchmaschinen indiziert?

Wie zu erwarten war, hat Google hier die Nase vorn. Wenn man sich den Marktanteil dieser Suchmaschine ansieht – im weltweiten Schnitt sind das über 90% bei mobilen Anwendungen – könnte man davon ausgehen, dass die Konsequenzen der neuen Frontend-Technologien schon nicht so drastisch sind. Aber zum einen ist diese Verteilung nicht in allen Ländern gleich, und zum zweiten bedeutet eine theoretische Indizierbarkeit noch nicht, dass es tatsächlich keine negativen Konsequenzen für Händler hat, die jahrelang viel Energie in die Positionierung ihrer Websites gesteckt haben. So etwas wie eine „Entwarnung“ diesbezüglich konnte ich bei meinen Recherchen nicht finden, möglicherweise ist jemand da draußen, der ein paar Fakten beisteuern möchte?

Kurz erwähnen möchte ich noch, dass es neben klassischen Suchmaschinen auch noch Archivierungsdienste wie archive.org gibt, die regelmäßig die Websites der Welt duplizieren und für die Nachwelt festhalten. Wer so etwas wie die WayBackMachine für eine gute Sache hält, sollte sich bewusst sein, dass die eigene digitale Historie möglicherweise nicht mehr so gut konserviert werden kann wie es bei klassischen Frontend-Technologien der Fall ist.

Android vs. iOS

Überspitzt formuliert sind SPAs und PWAs klar Google-Territorium. Nicht nur, weil das Unternehmen mit Angular selbst ein JS-Framework entwickelt und unters Volk gebracht hat, sondern weil der Ansatz bzw. die Definition von PWAs vom eigenen Chrome-Team stammt, genau wie das Analyse-Tool Lighthouse, das bei Frontend-Entwicklung gerne genutzt wird. Daher überrascht es nicht, dass PWA-Funktionen besser von Android- als von iOS-Geräten unterstützt werden. Es ist wohl die Ironie der Technik-Geschichte, dass Steve Jobs bei seiner ersten iPhone-Präsentation das Thema „Web-Apps“ als Basis für neue Applikationen vorstellte – der heute so lukrative App-Store mit all seinen nativen Apps stand damals noch nicht auf Apples Roadmap.

Steve Jobs sprach 2007 schon über SPAs

Bis heute hat also Android bezüglich Unterstützung von PWA-Funktionen die Nase vorn, wie man in dieser aufschlussreichen Liste aus Progressive Web Apps on iOS are here ablesen kann:

  • On Android you can store more than 50 Mb
  • Android doesn’t delete the files if you don’t use the app, but it can delete the files under storage pressure. Also, if installed or used a lot by the user the PWA can request Persistent Storage
  • Bluetooth access for BLE devices
  • Web Share for accessing native share dialog
  • Speech Recognition
  • Background Sync and Web Push Notifications
  • Web App Banner to invite the user to install the app
  • You can customize (a little bit) the splash screen and the orientations you want
  • With WebAPK and Chrome, users can’t install more than one instance of a PWA
  • With WebAPK and Chrome, the PWAs appears under Settings and you can see data usage; on iOS everything appears under Safari
  • With WebAPK and Chrome, the PWA manages intents for its URL, so if you get a link to the PWA, it will be opened in standalone mode and not within the browser’s window.

Merke: Wer eine oder mehrere dieser Unterstützungen benötigt, seine Zielgruppe aber vornehmlich bei iOS-Usern sieht (deren weltweiter Anteil von ca. 23% deutlich kleiner ist als bei Android), sollte sich das mit den PWAs noch einmal überlegen.

Zusammenfassung

Ich hoffe, ich konnte die wichtigsten Elemente der PWA-Diskussion näher beleuchten und ein paar Zusammenhänge erläutern. Als Fazit möchte ich diesen Artikel mit den wichtigsten Argumenten für und wider PWAs beschließen.

Pro:

  • Unterstützung von „nativen“ App-Funktionen wie Add-to-Homescreen, Push-Notifications“ und Caching
  • Durch Aufruf über mobilen Browser entfällt eine Installation
  • Erhöhte Sicherheit durch HTTPS
  • Erhöhte Geschwindigkeit

Contra:

  • Indizierungsproblematik (Suchmaschinen, Archivierungsdienste)
  • keine einheitlichen Standards (iOS vs. Android)
  • möglicherweise längere initiale Ladezeiten

Wie immer freuen wir uns über eine rege Beteiligung in den Kommentaren!

(Bild: pexels.com)

2 Kommentare

  1. Moin Roman, feiner Artikel … und schön zu sehen, dass Du Dir mal wieder die Hände mit Technik schmutzig machst. 🙂

    Zwei Themen vermisse ich in Deiner Übersicht: Zum einen Web Components als native UI-Bausteine, am besten mit einem Framework wie StencilJS. Zum anderen Microfrontends als „vertikale“ Plattform-Architektur, üblicherweise in Kombination mit JAMstack.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.