nicht angemeldet
Hi,
ich stehe gerade vor der Entscheidung, eine Applikation für Android zu entwickeln und bin mir nicht sicher, ob ich es mit HTML5 oder nativ als Android-App entwickeln sollte.
Im Zusammenhang mit dieser Frage schaute ich mir gerade den Talk zu diesem Thema von Google I/O an.
In diesem Zusammenhang habe ich mir (mal wieder) Gedanken gemacht, wie denn nun am sinnvollsten Webapplikationen aufgebaut sein sollten.
Ich differenziere mal zwei Möglichkeiten:
(a) die Seiten werden alle on-the-fly mit üblichen Techniken auf dem Server generiert und fertig an den Client übertragen. Ich gehe davon aus, dass hier komplett/weitgehend auf client-seitige Technologie abseits von HTML und CSS verzichtet werden kann (insbesondere kann man davon ausgehen, nicht von JavaScript abhängig zu sein).
(b) die Seiten liegen als statisches HTML vor, dynamische Inhalte (z.B. die Ergebnisse aus einer Datenabfrage) werden mit JavaScript in das Dokument eingefügt. Ich bezeichne dies mal dreist als die HTML5-Methode. Nicht-statische Inhalte würde ich per REST oder einem RPC-Weg per JavaScript übertragen und dann das Dokument aufbauen.
Ganz grob die Vor- und Nachteile der Methoden, wie ich sie derzeit sehe.
Mit der HTML5-Methode kann ich insbesondere durch das Manifest erreichen, dass sämtliche statischen Inhalte bereits auf dem Client vorhanden sind. Dies ist insbesondere dann wichtig, wenn die Verbindung zum Server nicht dauerhaft gewährleistet ist. Diese ist nur noch dann notwendig, wenn Informationen nachgeladen werden.
Mit REST+JSON gäbe es einen einfachen Weg, diese Informationen zu transportieren.
An serverseitiger Technologie hätte man "nur noch" reine Business-Logik.
Nachteil ist sicherlich, dass man vollkommen auf JavaScript angewiesen ist. Ich halte es nicht für vorstellbar, dass man als Fallback-Lösung für Anwender ohne JS auf Methode (a) zurückgreift, da sind die Vorteile der HTML5-Methode zu gering.
Mich persönlich reizt es, die HTML5-Methode einmal auszuprobieren.
Allerdings bin ich mir da ein wenig unsicher. Bei "alten" Projekten habe ich erlebt, dass eine Mischung der Dokumentgenerierung von serverseitiger und clientseitiger Technologie schwerer wartbar ist als reine serverseitige Lösungen, nichtsdestotrotz "musste" ich einige Male diesen Weg gehen (zugegebenermaßen aus Bequemlichkeit, denn der Weg, alle Informationen der Seite zu sichern, an den Server zu schicken und ein neues Dokument dort zu erstellen ist zwar fast immer möglich, aber IMHO manchmal eben mit Kanonen auf Spatzen geschossen, wenn man "nur" eine neue Zeile irgendwo einfügen will).
Mit der HTML5-Methode würde man den kompletten Gegenweg gehen: dynamische Seitenteile würden nur noch aus JavaScript rauskommen, vom Server kommt nichts dynamisches (außer die Funktionen der Web-Service).
Nun zu meinen Fragen:
Habt ihr euch mit einer solchen Frage mal beschäftigt? Habt ihr diese (für euch) beantworten können?
Ist der Weg, den ich als HTML5-Weg bezeichnet habe, überhaupt praktikabel? Habt ihr diesen vielleicht sogar mal irgendwo eingesetzt?
"Gängige Lehre" in diesem Forum ist "Unobtrusive JavaScript". Dies bezieht sich darauf, das Dokument selbst dann funktional zu halten, wenn JavaScript deaktiviert oder eingeschränkt ist. Ist es ein sinnvoller Weg, eine Web-Applikation (welche ja etwas anderes ist als ein "einfaches" Dokument) auf JavaScript aufzubauen, so daß diese ohne JS quasi unbenutzbar wird (**)?
*: mit nicht vorstellbar meine ich: es ist zwar technisch möglich, beide Methoden zu implementieren, halte es aber für unwahrscheinlich, dass man beides machen würde, da man doppelten Implementierungsaufwand hätte.
Obwohl insbesondere REST ja darauf ausgelegt ist, dies zu tun. Man könnte einfach anhand etwa des Accept-Headers unterscheiden, ob da jetzt ein Browser eine statische HTML-Seite haben will oder ob ihm die Inhalte etwa als JSON reichen, damit er diese client-seitig in einem selbstgewünschten Format darstellen kann.
**: diese Frage ist in meinem Fragekomplex eher akademischer Natur, da dies keine Applikation für die freie Wildbahn wird, sondern nur für einen eingeschränkten Anwenderkreis. Also liegt eine kontrollierte Umgebung vor.
Danke an alle, die sich durch meinen Text durchgewühlt haben :).
Bis die Tage,
Matti