Haben Sie mit einseitiger Webanwendung experimentiert, dh wo der Browser nur eine Seite vom Server "abruft", der Rest wird vom clientseitigen JavaScript-Code verarbeitet (ein gutes Beispiel für eine solche "Anwendungsseite" ist Google Mail)?
Was sind einige Vor- und Nachteile dieses Ansatzes für einfachere Anwendungen (wie Blogs und CMS)?
Wie gehen Sie beim Entwerfen einer solchen Anwendung vor?
Bearbeiten: Wie in der Antwort erwähnt, ist es schwierig, die Schaltfläche "Zurück", die Schaltfläche "Aktualisieren", die URL "Lesezeichen / Kopie" zu verwenden. Letzteres kann mit location.hash gelöst werden, ein Hinweis auf die verbleibenden zwei Probleme?
Ich nenne diese einseitigen Apps "langlebige" Apps.
Für "einfachere Anwendungen", wie Sie es sagen, ist es schrecklich. Dinge, die OOTB für Browser arbeiten plötzlich brauchen besondere Sorgfalt und Aufmerksamkeit:
Hinweis Ich sage nicht, dass Sie diese Dinge nicht mit Einzelseiten-Apps erledigen können. Ich sage, Sie müssen sich die Mühe machen, sie in den App-Code zu integrieren. Wenn Sie einfach unterschiedliche Ressourcen in verschiedenen URLs haben, funktionieren diese ohne zusätzlichen Entwickleraufwand.
Nun, für komplexe Apps wie Google Mail, Google Maps, gibt es folgende Vorteile:
Ein Problem mit langlebigen Apps sind Speicherlecks. Herkömmliche Sites, die eine neue Seite für jede Benutzeraktion anfordern, haben den zusätzlichen Vorteil, dass der Browser das DOM und alle nicht verwendeten Objekte in dem Maße verwirft, in dem der Speicher zurückgewonnen werden kann. Neuere Browser haben unterschiedliche Mechanismen dafür, aber nehmen wir den IE als Beispiel. IE erfordert besondere Sorgfalt, um Speicher während der Lebensdauer der langlebigen App regelmäßig zu bereinigen. Das wird heutzutage von Bibliotheken etwas erleichtert, ist aber keineswegs eine Trivialität.
Wie bei vielen Dingen ist ein hybrider Ansatz großartig. Es ermöglicht Ihnen, JavaScript für das Lazy-Laden bestimmter Inhalte zu nutzen, während Sie Teile der App nach Seiten / URLs trennen.
Ein Vorteil ist, dass Sie die volle Präsentationskraft von JavaScript erhalten, im Gegensatz zu nicht-JavaScript-Websites, auf denen der Browser zwischen Seiten und ähnlichen kleinen Störungen flackern kann. Möglicherweise stellen Sie fest, dass eine geringere Bandbreite verwendet wird und dass Sie nur mit den sofort wichtigen Teilen arbeiten müssen, die aktualisiert werden müssen, anstatt eine vollständige Webseite vom Server wiederherzustellen.
Der Hauptgrund dafür ist die Sorge um die Barrierefreiheit. Benutzer ohne JavaScript (oder diejenigen, die sie deaktivieren) können Ihre Website nicht verwenden, es sei denn, Sie führen eine ernsthafte serverseitige Codierung durch, um zu bestimmen, worauf Sie antworten sollen, je nachdem, ob die Anfrage mit AJAX erfolgt ist oder nicht. Abhängig davon, welches (serverseitige) Web-Framework Sie verwenden, kann dies entweder einfach oder extrem mühsam sein.
Es ist nicht als eine gute Idee im Allgemeinen eine Website zu haben, die vollständig auf dem Benutzer beruht, der JavaScript hat.
Ein großer Nachteil und eine große Beschwerde von Websites, die AJAX vielleicht ein bisschen zu weit genommen haben, ist, dass Sie die Möglichkeit verlieren, Seiten, die "tief" in den Inhalt der Website sind, zu bookmarken. Wenn ein Benutzer die Seite markiert, erhält er immer die "Front" -Seite der Website, unabhängig davon, welchen Inhalt er beim Erstellen des Lesezeichens betrachtet hat.
Vielleicht sollten Sie SproutCore (Apple hat es für MobileMe verwendet) oder Cappuccino , das sind Javascript-Frameworks, um genau das zu machen, Desktop-ähnliche Interfaces zu entwerfen, die nur Antworten vom Server über JSON oder XML abrufen.
Die Verwendung von entweder für einen Blog ist keine gute Idee, aber eine gut gestaltete Desktop-ähnliche Blog-Admin-Bereich kann eine Freude sein, zu verwenden.
Der Hauptgrund, es zu vermeiden, ist, dass es alleine genommen extrem suchunfreundlich ist. Das ist gut für Webapps wie GMail, die nicht öffentlich durchsuchbar sein müssen, aber für Ihre Blogs und CMS-gesteuerten Websites wäre es ein Desaster.
Sie könnten natürlich die einfache HTML-Version erstellen und sie dann progressiv erweitern, aber es kann ein Haufen Arbeit sein, es in beiden Versionen auf einmal gut zu machen.
Ich habe genau diese Art von Seiten als Webapps für das iPhone erstellt. Meine Methode bestand darin, alles in eine riesige index.html-Datei zu schreiben und bestimmte Inhalte auszublenden oder anzuzeigen. Dieses Anzeigen und Verbergen, d. H. Die Navigation der Seite, steuere ich in einer speziellen Javascript-Datei, wo die notwendigen Funktionen zur Handhabung der Darstellung der Teile in der Seite sind.
Pro: Alles ist am Anfang geladen und Sie müssen nichts mehr vom Server anfordern, z. Inhalte zu "schalten" und Aktionen auszuführen ist sehr schnell.
Con: Zuerst muss alles geladen werden ... das kann seine Zeit brauchen, wenn Sie viele Inhalte haben, die sofort angezeigt werden müssen.
Ein weiteres Problem ist, dass der Benutzer im Falle eines Verbindungsabbruchs nicht wirklich merkt, bis er tatsächlich die Serverseite benötigt. Das können Sie auch in Gmail feststellen. (Manchmal kann es aber auch positiv sein).
Hoffe es hilft! grüßt
Normalerweise werden Sie ein Framework wie GWT, Echo2 oder ähnliches verwenden.
Der Vorteil dieses Ansatzes ist, dass sich die Anwendung eher wie eine Desktop-App anfühlt. Wenn der Server schnell genug ist, werden die Benutzer die vielen kleinen Datenpakete, die hin und her gehen, nicht bemerken. Außerdem ist das Laden einer Seite von Grund auf eine teure Operation. Wenn Sie nur Teile davon ändern, kann der Browser einen Großteil des vorhandenen Modells im Speicher behalten und nur die geänderten Teile ändern.
Ein weiterer Vorteil dieser Frameworks ist, dass Sie Ihre Anwendung in reinem Java entwickeln können. Das heißt, Sie können es wie jede andere Java-Anwendung in Ihrer IDE debuggen, Sie können Komponententests schreiben und diese automatisch ausführen usw.
Ich füge hinzu, dass bei langsameren Rechnern eine große Menge an JavaScript den Browser zum Stillstand bringt. Da das gesamte Rendering clientseitig erfolgt, wenn der Benutzer keinen höherwertigen Computer besitzt, wird dies die Erfahrung ruinieren. Mein Arbeitscomputer ist ein P4 3.0GHZ mit 2 GB Ram und JavaScript-Schwerpunkten verursachen, dass es langsamer als Melasse tuckert, was wirklich die Benutzererfahrung für mich tötet.
Tags und Links javascript