War aber dann wohl doch zu lahm und wurde ersetzt. Was mich zu meiner Frage bringt: Woran erkennt man denn eine HTML5-App (außer dass sie lahm ist)?
Prinzipiell sind sie nicht zwangsläufig lahm. Es kommt drauf an, was man damit machen will
Und das viel Javascript nunmal auch viel Browserspeicher braucht sollte einem
HTML/JS-Entwickler klar sein. Dass dieser Speicher auf mobilen Geräten knapp ist auch.
Von daher kann man nicht mal einfach das komplette Facebook-Javascript was man für seine Seite hat 'mal schnell' hinter ein anderes, schlankereres UI klemmen, und dann eine iOS und Android 'App' schreiben, die diese spezielle Seite im Systemeigenen Browser anzeigt. Und das haben die (sehr blauäugig) gemacht. Waren halt auch ruck-zuck fertig, aber eben mit den bekannten Nachteilen.
Eine
Html(5)-App erkennt man ganz simpel daran, dass sie in aktuellen Browsern (Chrome, Firefox, IE ab 8/9 und Safari) läuft. Und mit HTML5 an sich kann man ne Menge machen. Ich schreibe gerade an einem HTML5-Artikel für das Entwickler-Magazin, wo ich mal so die wichtigsten Features des neuen Standards vorstellen will.
Ich meine, so Dinge wie die ganzen großen Web-Applications (Google Mail, Google Docs, Microsoft Office 365, Outlook.com) sind ja schonmal gute Beispiele, was da alles geht. Für lokale Speicherung braucht man inzwischen auch kein Gears mehr, sondern gut geschriebene HTML5-Anwendungen starten im Browser auch, wenn man gerade mal keine Internetverbindung hat und synchronisieren/updaten sich wieder, sobald sie da ist.
Das macht natürlich die Versionspflege für den Anbieter ungeheuer einfach (auf alle Webserver legen, alle User sind spätestens nach dem nächsten Aufruf up-to-date).
Und, man kann natürlich alle Plattformen die einen Webbrowser zur Verfügung stellen mit einer einzigen Version gleich bedienen.
Aber es ist halt nicht für alle Anwendungsfälle tauglich.
Zum einen läuft das Programm auf dem Client, und zwar aus JS heraus. Man rückt also zwangsläufig die Sourcen raus. Zum anderen sind so Sachen wie Numbercrunchimg im Browser ne saudoofe Idee. Zum dritten kann man in seiner Browser-Console alles eingeben was man will, und so auch beliebigen Code in jede Webanwendung einschleusen. Also muss alles was irgendwie 'wichtig' und aufwändig / teuer in Sachen performance ist oder eine gewisse Art von Security voraussetzt sowieso auf dem Backend (irgend ein Server) passieren.
Und es gibt nunmal Anwendungen, die gehen einfach (noch?) nicht in
HTML/JS (Treiber, VOIP Clients (z.B. wegen dem Transcodieren).