Im Folgenden wird deutlich, dass und auch warum es in den letzten Jahren reichlich Verwirrung in den Begrifflichkeiten gab, die allesamt nicht dienlich sind, um die eigentliche revolutionäre Wirkung der heutigen WebApps zu verstehen.

Nichts ist denglischer im Internet als der Ausdruck Webseite. Eigentlich hieß es „website“, als das Internet noch ein strikt angelsächsisches Medium war. Eine Webseite ist eine Seite. Eine Website ist ein Angebot, das mindestens eine HTML-Seite hat, also durchaus 100 HTML-Seiten haben kann. Hier wird auch offenbar, dass „HTML“ und „Web“ meist verwechselt werden, nicht nur das deutsche „Seite“ und das englischsprachige „site“. Das wird uns jetzt weiter verfolgen. ↑ top

Klingt ein wenig wie „Apple“. Eigentlich aber gar nichts Neues. Es stammt vom IT-Begriff „application“ = Anwendung. Die Windowsnutzer kennen das, der Bildschirm ist voller Anwendungen. Oder wie man früher sagte: „Computer-Programme“. Mache kennen sicher aber noch applets. Die Java-Programme in die HTML-Seite brachten. Aber eigentlich sind es nur Programme. Und es klingt nicht so old school und nach alten Betriebssystemen. „APP“ ist eben irgendwie neu, besonders „mobile App“. Mobil ist aber nur das Gerät, was ja auch ein Notebook, ja schon Laptop, der zurecht auch Schlepptop hieß, eigentlich ist …

Revolutionäre Ideen fangen mit revolutionären Begriffen an, mit neuen Begriffen für die alten Sachen, denn neue Menschen brauchen neue Begriffe für alte Sachen, wegen Identität und so. Gibt es bestimmt eine Studie, warum das so viel cooler ist. Vor allem verkauft es sich aber auch viel besser, wenn es viel neuer ist.

Eine „APP“ ist nichts anderes als ein Computerprogramm. Um eben kein nutzloses Programm zu haben, auch Viren sind Programme, aber ganz böse, hat man ein nützliches, eines, das man anwenden kann, also Microsofts alte Idee der Applikation.

Und - Apps sind viel cooler als Webseiten? Ja? Stimmt das? „Web ist tot“ verkünden die Mobil-Jünger. Man kann alles mit mobilen Apps machen. Cool, alles mobil.

Großer Irrtum: Mobil war doch nur ein Marketingtrick, um massig teure Endgeräte zu verkaufen. 10 Jahre mobile Welt bedeutet auch 10 Jahre voll mit millionenschweren Fehleinschätzungen.

Web ist lebendiger, als viele es wahrhaben wollen. Und das Zauberwort ist: WebApp. ↑ top

Webseiten, ob eine oder gar gleich ein ganzer Haufen Webseiten einer Site, werden oft einfach so auch „WebApp“ genannt, um diese von den Apps aus den Stores von Apple und Google irgendwie zu differenzieren.

Etwas unglücklich, denn auch in den Stores tauchte der Begriff „WebApp“ auf, was daran lag, dass Entwickler in einer native App, in z. B. Java programmiert, auch einen WebClient einbauen konnten, das sogenannte „WebViewObject“.

D. h. in diesen Shops gibt es vier Arten von Apps, die eben nicht ohne das Web auskommen.

a) Webbasierende Apps
Dies sind Apps, die z. B.: Daten aus dem Internet nachladen, bzw. Programme auf Webservern nutzen, und eben nicht ohne Internet funktionieren. Also - alle Soziale Netzwerke, alle Suchmaschinen, Shops, etc. Ursprünglich wurden die Ein- und Ausgabemasken noch mit Java programmiert.

b) Hybride Apps
So wurden Apps genannt, die eben einen WebClient enthalten, in dem auch Ein- und Ausgabe eigentlich durch einen Webserver aufgebaut werden.

c) Launcher Icons
Dies sind Apps, die gar nicht selbst Inhalte darstellen, sondern einfach eine bestimmte WebAdresse an die Umgebung des mobilen Endgerätes abgeben (share, teilen) und dann den Anwender bestimmen lassen, mit welcher Anwendung, bzw. welchem Browser er diese Internetadresse öffnen möchte. Hat dieser nur einen Browser zur Verfügung, wird die Adresse einfach so an diesen Browser weitergereicht und ein Fenster mit der Webseite geöffnet.

d) HTML-Apps
Wie schon so oft wird Web mit HTML verwechselt. Tatsächlich muss eine hybride App nicht eine Webseite im Internet zum Inhalt haben, sondern kann auch eine statische HTML-Seite auf dem mobilen Endgerät einspielen, bzw. sogar komplett in Javascript dynamisch generieren. Das Hybride an der hybriden App ist nämlich: Java und HTML5, und eben nicht mit oder ohne Web. ↑ top

Lange Zeit war hier eine bösartige Sollbruchstelle, denn ständig musste das Betriebssystem repariert werden, weil immer neue Hacks in diesem WebView-Client enthüllt wurden, was alle WebApps zu Unrecht unsicherer machte, als sie es vereinzelt eh schon waren. Kommt hinzu, dass die Hersteller von Smartphones kaum mit den Updates der Systeme für ihr mobiles Endgerät hinterherkamen, und ein 600 Euro Smartphone nach 2 Jahren bereits zur Zeitbombe wurde.

Seit Android 5 hat Google diese Komponente aus dem Betriebssystem herausgetrennt, so dass nun ein ständiges Update läuft und die Geräte allgemein „sicherer“ wurden.

Damit war die Stabilität der WebApps endlich unabhängig von der Kundenfreundlichkeit der Mobil-Unternehmen. ↑ top

Es geht ja darum, dass ein Anbieter sein Angebot irgendwie auf den Bildschirm der Millionen Smartphonenutzer bekommt. Problem war, dieser Weg ging nur durch die fetten Apps im Appstore.

Und es geht darum, dass ein Anbieter nicht zu viele Dinge mehrmals programmieren muss, und vor allem im sich schnell verändernden mobilen Markt nicht ständig nachzurüsten hat.

Native Apps müssen zudem für Apple, Android und alle anderen Systeme speziell angepasst werden. Durch die speziellen Anforderungen von Google und Apple etc. entwickelte sich das Internet immer mehr zurück in proprietäre Welten, die eigentlich mit dem echten Internet dann nichts mehr zu tun haben.

Außerdem ist die Installation von Apps über Stores auch eher eine ganz groß angelegte Schnüffelprozedur. Denn der Nutzer muss ein Konto in dem jeweiligen AppStore haben. Das Internet selbst aber sollte eigentlich anonym sein. Nun wurden auch die Anwender zur Ware.

Eine WebApp müsste also wenn, dann eher frei von Native-App-Einschränkungen und -Bedingungen sein.

Ein noch anders Problem waren die Endgeräte selbst. Immer kleiner wurden die Speicher. Wenn Megabyte große App-Bomben den Speicher zumüllen, ist das auch nicht gerade hilfreich. ↑ top

Fast unbemerkt von den Nutzern der Androidwelt hatte Apple seinen Nutzern schon längst ein TouchIcon spendiert und eine neue Funktion im Safari-Browser „add to screen“ oder eingedeutscht. „Zum Bildschirm Hinzufügen“ direkt aus dem Browser. Eigentlich stammt dieses Verfahren ja aus der Desktop-Welt, in der sich schon vor 20 Jahren Verknüpfungen auf den Bildschirm erlaubt waren, daher heißt es ja meist auch so: „Short-Cut“

War in den hybriden Apps das Icon im native Code, ist es nun in der HTML-Seite. Eigentlich eine tolle Idee, aber die Zukunft für Apple lag in der Bindung der Nutzer über native Apps an Clouds. Die ganzen Jahre schwappte aber diese Idee mit den TouchIcons, die auch viele Sites, sogar unwissentlich oder wissentlich, mit einbauten.

Ab hier, wo die Webseite dank eingebautem TouchIcon über den Browser direkt auf den Screen (Desktop) formschön verknüpft werden kann, ohne Java drum herum, reden wir heute von „Web Apps“.

Also - eine WebApp ist mindestens ein Link auf eine Seite mit einem TouchIcon, das extra für den Bildschirm hergestellt wurde, und sich auf den ersten Blick nicht von den herkömmlichen Apps aus dem Store unterscheidet. Dieselbe Funktion, klick auf ein Icon und husche zur Webseite dahinter, die native recht umfänglich zu entwickeln wäre, ist nun mit der Entwicklung der Webseite mitentwickelt. Eine Extra-„APP“ muss also ein Anbieter einer Website eigentlich gar nicht mehr erstellen.

Und dann stellte sich heraus, dass der große Konkurrent Google diese Idee viel besser ausschlachten könnte. Seit Anfang 2017 legt sich Google mit einer neuen Ansage mächtig ins Zeug:

Und die anderen ziehen nach:

Aber es wäre ja nicht Google, wenn Google das Ganze nicht gleich mit einer Reihe von Standards verbinden würde, die Google (Chrome) wichtig findet und dann im W3C mit den anderen Kollegen von Apple (Safari), Microsoft (Edge) und der Mozilla Foundation (Firefox) abstimmt. Denn eigentlich ist nicht nur das Ende der Appstores eingeläutet, sondern wohl auch das der diversen Betriebssysteme im mobilen Bereich (z. B. Microsoft) und das der sogenannten Addons in den Webbrowsern.

Warum nicht gleich für den Bildschirm in HTML5 programmieren?

Ja, denn diese WebApps, die es eben nicht nur im mobilen Bereich gibt, sondern auch auf PCs werden durch das HTML5 immer beliebter. Was auch bedeutet, dass dieses HTML5, genauer auch das Javascript mehr können muss. Auch dies ein Grund, warum mobile Apps oft in Java sind, weil sie eben auf das System zugreifen können. Java Apps sind sogar etwas übermächtig. ↑ top

Um ein Wirrwarr an WebApps-Definitionen zu umgehen, wurde der Begriff PWA erfunden.

Eine Webapp muss sicher sein (HTTPS-Server), schnell, responsive, also auf allen Geräten sich anpassend, es muss eine Offline-Lösung geben, ein eigener Cache für die Daten, damit nicht alles umherfliegt, und und und. Die Definitionen, was die TouchIcons sein sollen und wie die Grundfarben, der Name, etc. wird über ein einheitliches maschinenlesbares Protokoll geregelt, das Webmanifest.

Weitere Definitionen und Funktionen übernehmen „Serviceworker“, also Programme die dann laufen, wenn diese WebApps bereits auf dem Endgerät installiert sind. Natürlich sollen sie so mächtig werden, wie die Apps aus dem Store. Sie sollen ihre Nutzer nerven können mit immer neuen Infos, und auch Werbeschaltung soll einbaubar sein, und natürlich alle Apis, die auch schon so in der Web-Welt zu haben sind, wie etwa Google Maps. ↑ top

Google schließt in Chrome nun die Lücke zwischen nativer App und WebApp. Wird eine progressive WebApp installiert, bedeutet das für Chrome, dass sie tatsächlich zu einer echten App umgewandelt wird, mit einem WebClient drumherum, so ähnlich wie bei WebView, nur dass der Browser Chrome das von selbst macht.

Erster kleiner Unterschied: Eine Webseite in einem WebView-Client als hybride App aus dem Store ist mindesten 1 MegaByte groß - was viel Speicherplatz auf dem Smartphone ist. Eine WebAPK ist um 50 KiloByte groß, soviel Bytes eben diese TouchIcons brauchen.

Zweiter Unterschied: Die App wird nicht über den Store installiert, sondern direkt von der Webseite. Und nun wird klar, was Google mit „searchable“ meint. Die App ist natürlich nun so über Googles Suchmaschine und alle anderen auffindbar, wie eben auch die Webseite aufgefunden werden kann. Webseitenhersteller bauen sich also keine eigene Konkurrenz mit ihrer App mehr auf.

Die WebAPK lässt sich auch einfach mit anderen Nutzern teilen. APK ist das Kürzel für das Installationsdateiformat, Android Package, das die Apps aus den Stores haben.