Gibt es eine solide Begründung dafür, warum Websites nicht mit Ajax-Funktionen entwickelt werden sollten, die große Teile jedes Teils laden (vorausgesetzt, es gibt Elemente wie Header, Navigation usw., die gleich bleiben)?

Sicherlich wäre es weniger ressourcenintensiv, da der Server nicht Inhalte bereitstellen müsste, die auf jeder Seite angezeigt werden, was sowohl dem Host als auch dem Endbenutzer zugute kommt.

Beantworten Sie die Frage unter Berücksichtigung:

• Das Javascript-Verhalten der Site verschlechtert sich in jedem Fall erheblich

• Bei meiner Frage spreche ich von neuen Websites, auf denen dieses Verhalten eher von Anfang an implementiert werden könnte, sodass es technisch kein Geld kostet - wir kehren nicht zu einem fertigen Produkt zurück, um es zu implementieren.

Wenn der Inhalt ohne aktiviertes JavaScript erreicht werden kann, macht Ihre Frage keinen Sinn. Es ist nicht "vollständig Ajaxified", wenn Sie auf andere Weise zum Inhalt gelangen können. Sie fragen sich wirklich: "Ist es in Ordnung, die Benutzererfahrung durch Ajax zu verbessern?". Die Antwort lautet offensichtlich "Ja".

bearbeiten

Als Google seinen crawlbaren Ajax-Vorschlag herausbrachte, war dies eine wirklich schlechte Idee . Für eine interessante Lektüre.

Das wichtigste zuerst

Die Profis

• Mit AJAX können Sie eine gemeinsame "Basisseite" verwenden und nur die Inhaltsbereiche laden, wodurch sich die Ladezeit für Benutzer verkürzen lässt, da ein großer Teil der Seite bereits geladen ist.
• Kann eine Augenweide zulassen, z. B. das Ein- und Ausblenden des Inhaltsbereichs.

Die Nachteile

• Spielt nicht gut, wenn die Seite heruntergeladen wird.
• Kann mit Geräten mit Behinderung herumspielen.
• Zuschauer mit deaktiviertem Javascript können den Inhalt nur verwenden, wenn auch eine Nicht-Javascript-Version verwendet wird.
• Viel mehr Arbeit (muss das wirklich gesagt werden?).

Nun zu Ihrer Frage

Angenommen, Ihre Website verschlechtert sich für diejenigen ohne Javascript in angemessener Weise. Wie gut sich das herausstellt, hängt davon ab, wie es gemacht wird. Wenn Sie beispielsweise nur aus heiterem Himmel einen Link zu einer Nicht-Javascript-Version anzeigen, ist es für diese Betrachter unangenehm, auf einen anderen Link klicken zu müssen. Wenn es andererseits eine Noscript- "Hauptseite" gibt, die herkömmliche Links verwendet, funktioniert dies für die meisten Benutzer besser, aber für diejenigen, die Geräte mit Behinderung verwenden, fehlt die Unterstützung, wenn der Benutzer eine bestimmte "Seite" von a Link usw.

Alles in allem ist es in der Welt der immer schnelleren Webverbindung nicht wirklich gerechtfertigt, eine kleine Menge an Dateigröße abzuschneiden (wir gehen davon aus, dass das gesamte Javascript selbst, das CSS und die Bilder zwischengespeichert werden können und werden, wobei nur übrig bleiben die "Basis" -Seite selbst, auf der Bytes gespeichert werden können) für die Nachteile, die sie bieten kann, nämlich die zusätzliche Schwierigkeit (obwohl dies nicht immer eine Herausforderung ist) und die mangelnde Unterstützung, die sie einigen Benutzern bieten kann.

Alles in allem würde ich sagen, es liegt an Ihnen, es würde wahrscheinlich ziemlich gut funktionieren, und für die große Mehrheit der Benutzer werden sie die Site wahrscheinlich wie beabsichtigt sehen, aber persönlich würde ich sagen, nicht stören, da es sich nicht lohnt, eine solche marginale Verbesserung der Dateigröße vorzunehmen.

Schauen Sie sich http://gawker.com/ an - diese Seite wird nachträglich fast vollständig geladen. Sie verwenden "Hashbangs" ( http://mydomain.com/#!some_section), um zu bestimmen, welche Inhaltsseite geladen werden soll. Die Hauptnavigation bleibt statisch.

Unter http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ finden Sie ein kurzes Tutorial zum verwendeten Konzept von Gawker.

Es gibt Vor- und Nachteile, Sie müssen Suchmaschinen berücksichtigen (siehe http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), Menschen mit deaktiviertem Javascript und viele Tests durchführen.

Nach alledem ist das größte Argument gegen sie wahrscheinlich, dass ein Benutzer ungeduldig sein kann, wenn er auf das Laden einer Seite wartet und dann auf das Laden einer Seite warten muss. Meiner Ansicht nach besteht die beste Vorgehensweise darin, die Hauptwebsite, die Navigation und den primären Inhalt in einem Durchgang (auf Anfrage) zu laden und die AJAX für die nicht wesentlichen Nebenkosten zu speichern. Das funktioniert mit der Idee der progressiven Verbesserung und mischt das Beste aus beiden Ansätzen.

Weil es wahrscheinlich einfach nicht nötig ist.
Das Laden grundlegender HTML-Dokumente ist einfach und funktioniert. Durch die Einführung von Ajax wird eine weitere Prozessschicht für Browser, Code und Wartung für Javascript, Back-End-Inhalte, seltsame Hashbang-URLs usw. hinzugefügt. Manchmal kann dies gerechtfertigt sein, manchmal nicht. Es könnte Ihnen einige Serverressourcen sparen (könnte), aber wird das ausreichen, um den Unterhalt auszugleichen? Sie müssen das pro Projekt bewerten.

Als Twitter beispielsweise das neueste Redesign erhielt, gingen sie davon aus, dass es sich nicht nur um eine Webseite (Seite) handelt, sondern um eine Anwendung, und das Ganze basiert stark auf Ajax, obwohl das meiste, was es kann mit regulären Seitenanfragen behandelt werden. Eines der größten Probleme, das jetzt noch viel weniger auftritt, besteht darin, dort anzukommen und mit einer leeren Seite begrüßt zu werden, weil etwas im Ajax fehlgeschlagen ist.

In der Praxis ist es eine Menge Arbeit, eine "vollständig AJAX" -Website zu erstellen, insbesondere für große Websites, die sehr kompliziert sind. Einige Websites, die dies versuchen, sind Google und Facebook, aber selbst sie machen es nicht perfekt.

Häufige Probleme sind Navigation (dh vorwärts und rückwärts) und Lesezeichen, aber es gibt viele andere Fehler, mit denen sich viele Entwickler lieber nicht befassen müssten. Und es bedeutet im Grunde, zwei Versionen der Website zu erstellen, die mit Javascript- und Nicht-Javascript-Benutzern kompatibel sind (und Korrekturen für alle Browser mit schlechter AJAX-Unterstützung).

Ja, es sollte sein, aber es sollte umgekehrt sein.

Die allgemeinen Teile der Seite sollten über HTTP gesendet werden. Dann lädt ein kleines Ajax-Steuerelement (oder noch besser Websockets) den dynamischen Inhalt asynchron.

Natürlich müssen Sie zuerst feststellen, ob Javascript aktiviert ist (per Cookie), und diese Methode nur verwenden, wenn sie aktiviert ist.

Sie benötigen also die normale vollständige HTTP-Route und dann eine Websockets-Route. Dies erfordert eine Codeduplizierung, es sei denn, Sie verwenden ein Tool wie node.js.

Die meisten Leute "denken", dass es den zusätzlichen Aufwand einfach nicht wert ist. Und manchmal ist es nicht.

Abgesehen davon ajaxifizieren viele Leute Seiten falsch. Sie entscheiden tatsächlich, dass Sie keine Nicht-Javascript-Version benötigen und dass Sie all diese seltsamen Hash-Bang-URLs und kaputten Vorwärts- / Rückwärts-Schaltflächen benötigen. Um Ajax richtig zu machen, ist ein HTML5-Verlauf erforderlich (IE9 hat ihn nicht). Außerdem muss der Entwickler die Versionen Ihrer Website vervollständigen.

Da Sie angegeben haben, dass sich dies für Besucher mit deaktiviertem Javascript erheblich verschlechtern würde, sehe ich nur zwei echte Probleme (und ein mögliches Problem), die möglicherweise auftreten.

Schlecht für die Zugänglichkeit

Screenreader und andere unterstützende Technologien werden häufig durch dynamische DOM-Änderungen beeinträchtigt. Sie verarbeiten und lesen die Seite linear, und das Ändern des Inhalts der Seite nach dem Laden wird möglicherweise nicht korrekt behandelt.

Es mag Techniken geben, um dies zu umgehen, aber ich habe mich nicht allzu gründlich damit befasst.

Erhöhte Komplexität

Die Pflege dieser Art von Website kann schwierig sein. Ein Beispiel: Wenn Sie ein neues Layout erstellt und die ID des Inhaltsbereichs geändert haben, den Sie durch Ihre AJAX-Links ersetzt haben, kann dies Ihr Navigationsschema auf ziemlich verwirrende Weise beschädigen.

Diese Art von AJAX-Verhalten würde auch jede von Ihnen durchgeführte Verkehrsanalyse erschweren. Google Analytics würde diese AJAX-Ladevorgänge ohne einen manuellen Aufruf von nicht ordnungsgemäß registrierenpageTracker._trackPageview('this_page'); .

Wenn Sie die Funktionsweise Ihrer Seite komplexer gestalten, wird auch die Messlatte für neue Entwickler höher gelegt. Jeder, der auf der Website arbeitet, muss wahrscheinlich darüber informiert werden, wie sich dieses Verhalten auf das Laden von Seiten auswirkt.

Möglich: Langsameres Laden der Seite beim ersten Besuch

Abhängig davon, wie Sie die Dinge strukturieren, kann diese Seite, auf der AJAX-Code abgerufen wird, erst aktiviert werden, nachdem das Dokument vollständig geladen wurde. Erst nachdem Ihr Besucher die gesamte Seite und dann das Javascript (wenn es sich um eine externe Datei handelt) heruntergeladen und der Browser sie gerendert und den Inhalt über AJAX abgerufen hat, wird der Seiteninhalt angezeigt.

Jeder nachfolgende Link, auf den geklickt wird, ist schneller, aber das Abrufen der ersten Seite, die ein Benutzer besucht hat, würde tatsächlich länger dauern als eine statische Version.

Der Grund, warum ich dies als mögliches Problem bezeichnet habe, ist, dass Sie die erste Seite immer statisch senden können (da Sie die statische Version bereits als Fallback haben) und dann AJAX für die nachfolgenden Links verwenden können.

Für das, was es wert ist, klingt dies für mich nicht nach einer schrecklichen Idee - insbesondere für bandbreitensensitive Anwendungen wie mobile Seiten. Sie müssten die Nachteile jedoch sorgfältig abwägen, um sicherzustellen, dass es sich in Ihrem Fall lohnt.

Ajax-Elemente auf einer Seite zu haben ist in Ordnung, wenn Sie eine kleine Benutzerbasis haben, aber mehr Verkehr haben. Sie möchten einen statischeren Ansatz verwenden, um den Missbrauch von Ressourcen zu verringern.

Beispiel: Angenommen, Sie haben 200 Personen, die pro Sekunde versuchen, auf eine Seite zuzugreifen. Sie haben ungefähr 7 Datenbankabfragen für Ihre Ajax-Aufrufe. Das sind 1400 Datenbankaufrufe pro Sekunde, die eine Website blockieren können.

Eine Website, die für einen höheren Datenverkehr ausgelegt sein muss, sollte statische, nach außen gerichtete Seiten aufweisen, damit Inhalte statisch angezeigt werden können. Dies wird erreicht, indem ein serverseitiges Skript verwendet wird, das jede Sekunde ausgeführt wird, um die statische Seite neu zu erstellen, die für den Endbenutzer abgerufen wird. Auf diese Weise haben Sie Ihre Last von 1400 Datenbankaufrufen pro Sekunde auf 7 reduziert.

Es ist ein SOA- Ansatz für die Erstellung von Websites.