WebApp, Website, App - Begriffserklärung
Was ist was und heißt warum eigentlich wie?
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.
Webseite
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
App
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
WebApp Nr.1 WebView (HTML-Fenster in der Java-Code)
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.
Documentation WebView
https://developer.android.com/reference/android/webkit/WebViewD. 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
Android System WebView
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.
PlayStore: Android System WebView
https://play.google.com/store/apps/details?id=com.google.android.webviewDamit war die Stabilität der WebApps endlich unabhängig von der Kundenfreundlichkeit der Mobil-Unternehmen. ↑ top
So, hier machen wir jetzt einmal entspannt einen Cut, denn das alles ist Schnee von gestern. Schön für die Geschichtsbücher, aber das wird zukünftige Generationen nicht mehr interessieren.
Denn worum geht es eigentlich?
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
WebApp Nr.2 ADD-TO-SCREEN
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.
Configuring Web Applications
https://developer.apple.com/.../ConfiguringWebApplications.htmlAb 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:
Progressive Web Apps (Google, Chrome)
A new way to deliver amazing user experiences on the web.
https://developers.google.com/web/progressive-web-apps/Und die anderen ziehen nach:
Progressive web apps (Mozilla Foundation, Firefox)
//developer.mozilla.org/.../Apps/ProgressiveProgressive Web Apps on Windows (Microsoft, Edge)
https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-appsAber 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
Progressive WebApp (PWA)
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.
WebApp Manifest
https://www.w3.org/TR/appmanifest/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
Dem noch nicht genug:
WebApp Nr.3 WebAPK
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.