it-swarm.com.de

Single Page Application: Vor- und Nachteile

Ich habe über SPA und seine Vorteile gelesen. Die meisten finde ich nicht überzeugend. Es gibt 3 Vorteile, die meine Zweifel wecken.

Frage: Können Sie als Anwalt von SPA auftreten und beweisen, dass ich mich irre Die ersten drei Aussagen?

                              === ADVANTAGES ===

1. SPA ist extrem gut für sehr reaktionsschnelle Websites:

Das serverseitige Rendern ist für alle Zwischenzustände schwer zu implementieren - Zustände der kleinen Ansicht lassen sich URLs nicht gut zuordnen.

Einseitige Apps zeichnen sich dadurch aus, dass sie einen beliebigen Teil der Benutzeroberfläche neu zeichnen können, ohne dass ein Server-Roundtrip zum Abrufen von HTML erforderlich ist. Dies wird erreicht, indem die Daten von der Datenpräsentation getrennt werden, indem eine Modellebene, die Daten verarbeitet, und eine Ansichtsebene, die aus den Modellen liest, vorhanden sind.

Was ist falsch daran, eine Modellebene für Nicht-SPA zu halten? Ist SPA die einzige kompatible Architektur mit MVC auf der Clientseite?

2. Mit SPA müssen wir keine zusätzlichen Anfragen an den Server stellen, um Seiten herunterzuladen.

Hah, und wie viele Seiten können Benutzer während des Besuchs Ihrer Website herunterladen? Zwei drei? Stattdessen treten weitere Sicherheitsprobleme auf und Sie müssen Ihre Anmeldeseite, Administrationsseite usw. in separate Seiten aufteilen. Dies widerspricht wiederum der SPA-Architektur.

.Könnten Sie noch weitere Vorteile haben? Hören Sie nichts anderes ..

                            === DISADVANTAGES ===
  1. Der Client muss Javascript aktivieren.
  2. Nur ein Einstiegspunkt in die Site.
  3. Sicherheit.

P.S. Ich habe an SPA- und Nicht-SPA-Projekten gearbeitet. Und ich stelle diese Fragen, weil ich mein Verständnis vertiefen muss. Kein Mittel, um SPA-Anhängern Schaden zuzufügen. Bitten Sie mich nicht, ein bisschen mehr über SPA zu lesen. Ich möchte nur Ihre Überlegungen dazu hören.

193
VB_

Werfen wir einen Blick auf eine der beliebtesten SPA-Websites, GMail.

1. SPA ist extrem gut für sehr reaktionsschnelle Websites:

Das serverseitige Rendern ist nicht mehr so ​​schwierig wie früher mit einfachen Techniken wie dem Behalten eines #hash in der URL oder in jüngerer Zeit HTML5 pushState . Bei diesem Ansatz wird der genaue Status der Webanwendung in die Seiten-URL eingebettet. Wie in GMail wird bei jedem Öffnen einer E-Mail ein spezielles Hash-Tag zur URL hinzugefügt. Beim Kopieren und Einfügen in ein anderes Browserfenster kann genau dieselbe E-Mail geöffnet werden (vorausgesetzt, sie können sich authentifizieren). Dieser Ansatz ist direkt einer traditionelleren Abfragezeichenfolge zugeordnet, der Unterschied liegt lediglich in der Ausführung. Mit HTML5 pushState () können Sie das #hash und verwenden Sie vollständig klassische URLs, die bei der ersten Anforderung auf dem Server aufgelöst und bei nachfolgenden Anforderungen über Ajax geladen werden können.

2. Mit SPA müssen wir keine zusätzlichen Anfragen an den Server stellen, um Seiten herunterzuladen.

Die Anzahl der Seiten, die der Benutzer während des Besuchs meiner Website herunterlädt? wirklich, wie viele Mails einige lesen, wenn er/sie sein/ihr Mailkonto eröffnet. Ich lese> 50 auf einmal. jetzt ist der Aufbau der Mails fast gleich. Wenn Sie ein serverseitiges Rendering-Schema verwenden, wird es vom Server bei jeder Anforderung gerendert (typischer Fall). - Sicherheitsbedenken - Sie sollten/sollten keine separaten Seiten für die Administratoren/Anmeldedaten führen, die vollständig von der Struktur Ihrer Website abhängen Benutzer Ich meine, ich verwende Formulare für meine Spa-Website. - im wahrscheinlich am häufigsten verwendeten SPA-Framework Angular JS) kann der Entwickler den gesamten HTML-Tempel von der Website laden, so dass dies abhängig von der Authentifizierungsstufe des Benutzers erfolgen kann Typen ist nicht SPA.

3. Kann irgendwelche anderen Vorteile sein? Höre nichts anderes ..

  • heutzutage können Sie davon ausgehen, dass der Client über JavaScript-fähige Browser verfügt.
  • nur ein Einstiegspunkt der Site. Wie ich bereits erwähnt habe, können Sie eine beliebige Anzahl von Eintrittspunkten haben, aber Sie sollten auf jeden Fall einen haben.
  • auch in einem SPA muss der Benutzer nur darauf achten, welche Rechte er hat. Sie müssen nicht alles auf einmal spritzen. Das Laden von Diff-HTML-Vorlagen und Javascript Async ist ebenfalls ein gültiger Bestandteil von SPA.

Mir fallen folgende Vorteile ein:

  1. das Rendern von HTML erfordert offensichtlich einige Ressourcen, jetzt tut dies jeder Benutzer, der Ihre Website besucht. Außerdem wird nicht nur das Rendern von Hauptlogiken jetzt clientseitig statt serverseitig ausgeführt.
  2. probleme mit Datum und Uhrzeit - Ich gebe dem Client nur die UTC-Zeit als voreingestelltes Format an und kümmere mich nicht einmal um die Zeitzonen, mit denen ich Javascript umgehen lasse. Dies ist ein großer Vorteil für den Fall, dass ich Zeitzonen basierend auf dem Standort erraten musste, der von der IP-Adresse des Benutzers abgeleitet wurde.
  3. für mich ist der Status in einem SPA besser zu pflegen, denn sobald Sie eine Variable festgelegt haben, wissen Sie, dass sie vorhanden ist. Dies vermittelt eher das Gefühl, eine App als eine Webseite zu entwickeln. Dies hilft in der Regel viel bei der Erstellung von Websites wie Foodpanda, Flipkart, Amazon. Wenn Sie den clientseitigen Status nicht verwenden, verwenden Sie teure Sitzungen.
  4. websites sind mit Sicherheit äußerst reaktionsschnell - ich nehme ein extremes Beispiel für diesen Versuch, einen Taschenrechner in einer Nicht-SPA-Website zu erstellen (ich weiß, dass dies seltsam ist).

Aktualisierungen von Comments

Es scheint nicht so, als würde jemand über Sockets und Langzeit-Polling sprechen. Wenn Sie sich von einem anderen Client, beispielsweise einer mobilen App, abmelden, sollte sich auch Ihr Browser abmelden. Wenn Sie SPA nicht verwenden, müssen Sie die Socket-Verbindung bei jeder Umleitung neu erstellen. Dies sollte auch bei Aktualisierungen von Daten wie Benachrichtigungen, Profilaktualisierungen usw. Funktionieren

Eine alternative Perspektive: Wird Ihr Projekt neben Ihrer Website eine native mobile App beinhalten? Wenn ja, werden Sie höchstwahrscheinlich Rohdaten von einem Server (z. B. JSON) in diese native App einspeisen und clientseitige Verarbeitung durchführen, um sie zu rendern. Richtig? Mit dieser Behauptung machen Sie BEREITS ein clientseitiges Rendering-Modell. Nun stellt sich die Frage, warum Sie nicht dasselbe Modell für die Website-Version Ihres Projekts verwenden sollten. Ein bisschen ein Kinderspiel. Dann stellt sich die Frage, ob Sie serverseitige Seiten nur aus Gründen der SEO-Vorteile und der Benutzerfreundlichkeit von gemeinsam nutzbaren/mit Lesezeichen versehenen URLs rendern möchten

140
Parv Sharma

Ich bin Pragmatiker und werde versuchen, dies in Bezug auf Kosten und Nutzen zu untersuchen.

Beachten Sie, dass ich für jeden Nachteil, den ich gebe, anerkenne, dass sie lösbar sind. Deshalb betrachte ich nichts als Schwarzweiß, sondern als Kosten und Nutzen.

Vorteile

  • Einfachere Statusverfolgung - Sie müssen keine Cookies, Formulareingaben, lokalen Speicher, Sitzungsspeicher usw. verwenden, um den Status zwischen zwei Seitenladevorgängen zu speichern.
  • Der Inhalt jeder Seite (Kopfzeile, Fußzeile, Logo, Copyright-Banner usw.) wird nur einmal pro typischer Browsersitzung geladen.
  • Keine Overhead-Latenz beim Wechseln von "Seiten".

Nachteile

  • Leistungsüberwachung: Die meisten Lösungen für die Leistungsüberwachung auf Browserebene haben sich ausschließlich auf die Ladezeit der Seite konzentriert, z. B. auf die Zeit bis zum ersten Byte, die Zeit zum Erstellen des DOM, den Netzwerk-Roundtrip für HTML, das Onload-Ereignis usw. Aktualisieren der Seite Nachladen über AJAX würde nicht gemessen werden. Es gibt Lösungen, mit denen Sie Ihren Code instrumentieren können, um explizite Messwerte aufzuzeichnen, z. B. beim Klicken auf einen Link, Starten eines Timers und Beenden eines Timers nach dem Rendern des AJAX, und senden Sie dieses Feedback. New Relic unterstützt beispielsweise diese Funktionalität. Durch die Verwendung eines SPA haben Sie sich nur an wenige mögliche Tools gebunden.
  • Sicherheits-/Penetrationstests - Hand in Hand: Automatisierte Sicherheits-Scans können Probleme beim Auffinden von Links haben, wenn Ihre gesamte Seite dynamisch von einem SPA-Framework erstellt wird. Es gibt wahrscheinlich Lösungen dafür, aber auch hier haben Sie sich selbst eingeschränkt.
  • Bündelung: Wenn Sie beim ersten Laden der Seite den gesamten für die gesamte Website erforderlichen Code herunterladen, kann dies bei Verbindungen mit geringer Bandbreite zu Problemen führen. Sie können Ihre JavaScript- und CSS-Dateien bündeln, um zu versuchen, sie im Laufe der Zeit in natürlicheren Blöcken zu laden. Jetzt müssen Sie diese Zuordnung jedoch beibehalten und darauf achten, dass unbeabsichtigte Dateien über nicht realisierte Abhängigkeiten abgerufen werden (was mir gerade passiert ist). Wieder lösbar, aber kostenpflichtig.
  • Big-Bang-Refactoring: Wenn Sie beispielsweise eine größere architektonische Änderung vornehmen möchten, wechseln Sie von einem Framework zu einem anderen, um das Risiko zu minimieren, ist es wünschenswert, inkrementelle Änderungen vorzunehmen. Beginnen Sie mit der neuen Version, migrieren Sie auf einer bestimmten Basis, z. B. pro Seite, pro Feature usw., und löschen Sie die alte Version anschließend. Mit der herkömmlichen mehrseitigen App können Sie eine Seite von Angular zu Reagieren wechseln und dann eine andere Seite im nächsten Sprint. Mit einem SPA ist alles oder nichts. Wenn Sie ändern möchten, Sie müssen die gesamte Anwendung auf einmal ändern.
  • Komplexität der Navigation: Es gibt Tools, mit denen der Navigationskontext in SPAs wie history.js, Angular 2), die meist auf dem URL-Framework (#) oder der neueren Verlaufs-API basieren, beibehalten werden kann Jede Seite war eine eigene Seite, das brauchst du nicht.
  • Komplexität beim Herausfinden von Code: Websites verstehen wir natürlich als Seiten. Eine mehrseitige App partitioniert den Code in der Regel seitenweise, wodurch die Wartbarkeit verbessert wird.

Wiederum erkenne ich, dass jedes dieser Probleme zu einem gewissen Preis lösbar ist. Aber irgendwann verbringen Sie Ihre ganze Zeit damit, Probleme zu lösen, die Sie soeben hätten vermeiden können. Es kommt auf die Vorteile und wie wichtig sie für Sie sind.

60
Brandon

Nachteile

1. Der Client muss Javascript aktivieren. Ja, das ist ein klarer Nachteil von SPA. In meinem Fall kann ich davon ausgehen, dass meine Benutzer JavaScript aktiviert haben. Wenn Sie nicht können, können Sie kein SPA machen, Punkt. Dies entspricht dem Versuch, eine .NET-App auf einem Computer bereitzustellen, auf dem .NET Framework nicht installiert ist.

2. Nur ein Einstiegspunkt in die Site. Ich löse dieses Problem mit SammyJS . 2-3 Tage Arbeit, um Ihr Routing richtig einzurichten, und die Benutzer können Deep-Link-Lesezeichen in Ihrer App erstellen, die korrekt funktionieren. Ihr Server muss nur einen Endpunkt bereitstellen - den Endpunkt "Geben Sie mir HTML + CSS + JS für diese App" (stellen Sie sich diesen als Download-/Aktualisierungsspeicherort für eine vorkompilierte Anwendung vor) - und das clientseitige JavaScript, das Sie schreiben den eigentlichen Einstieg in die Anwendung erledigen.

3. Sicherheit. Dieses Problem betrifft nicht nur SPAs. Sie müssen mit der Sicherheit genauso umgehen, wenn Sie eine Client-Server-App der "alten Schule" (die HATEOAS-Modell für die Verwendung von Hypertext zum Verknüpfen von Seiten. Es ist nur so, dass der Benutzer die Anforderungen und nicht Ihr JavaScript ausführt und die Ergebnisse in HTML und nicht in JSON oder einem anderen Datenformat vorliegen. In einer Nicht-SPA-App müssen Sie die einzelnen Seiten auf dem Server sichern, während Sie in einer SPA-App die Datenendpunkte sichern müssen. (Und wenn Sie nicht möchten, dass Ihr Client auf den gesamten Code zugreifen kann, müssen Sie das herunterladbare JavaScript auch in separate Bereiche aufteilen. Ich binde es einfach in mein SammyJS-basiertes Routing-System ein, sodass der Browser nur anfordert Dinge, von denen der Client weiß, dass er Zugriff darauf haben sollte, basierend auf dem anfänglichen Laden der Benutzerrollen.

Vorteile

  1. Ein großer architektonischer Vorteil eines SPA (der selten erwähnt wird) ist in vielen Fällen die enorme Reduzierung der "Gesprächigkeit" Ihrer App. Wenn Sie es so entwerfen, dass es die meiste Verarbeitung auf dem Client ausführt (immerhin der springende Punkt), wird die Anzahl der Anforderungen an den Server (siehe "Möglichkeiten für 503 Fehler, die Ihre Benutzererfahrung ruinieren") drastisch reduziert. Tatsächlich ermöglicht ein SPA die vollständige Offline-Verarbeitung, was in manchen Situationen riesig ist.

  2. Die Leistung beim clientseitigen Rendern ist sicherlich besser, wenn Sie es richtig machen. Dies ist jedoch nicht der überzeugendste Grund, ein SPA zu erstellen. (Die Netzwerkgeschwindigkeiten verbessern sich schließlich.) Machen Sie nicht nur auf dieser Basis eine gute Figur für SPA.

  3. Flexibilität in Ihrem UI-Design ist vielleicht der andere große Vorteil, den ich gefunden habe. Nachdem ich meine API (mit einem SDK in JavaScript) definiert hatte, konnte ich mein Front-End mit null Auswirkungen auf den Server abgesehen von einigen statischen Ressourcendateien vollständig umschreiben. Versuchen Sie das mit einer herkömmlichen MVC-App! :) (Dies ist hilfreich, wenn Sie sich über Live-Bereitstellungen und die Versionskonsistenz Ihrer API Gedanken machen müssen.)

Fazit: Wenn Sie eine Offline-Verarbeitung benötigen (oder zumindest möchten, dass Ihre Kunden gelegentliche Serverausfälle überstehen) - was Ihre eigenen Hardwarekosten drastisch senkt - und Sie von JavaScript und modernen Browsern ausgehen können, benötigen Sie ein SPA. In anderen Fällen ist es eher ein Kompromiss.

40
Lars Kemmann

Ein großer Nachteil von SPA - SEO. Erst kürzlich haben Google und Bing begonnen, Ajax-basierte Seiten durch Ausführen von JavaScript während des Crawls zu indizieren, und in vielen Fällen werden Seiten immer noch falsch indiziert.

Während der Entwicklung von SPA werden Sie gezwungen sein, SEO-Probleme zu lösen, indem Sie wahrscheinlich Ihre gesamte Website nachrendern und statische HTML-Snapshots für die Verwendung durch Crawler erstellen. Dies erfordert eine solide Investition in eine ordnungsgemäße Infrastruktur.

Update 19.06.16:

Seitdem ich diese Antwort vor einiger Zeit geschrieben habe, sammle ich viel mehr Erfahrung mit Single Page Apps (AngularJS 1.x), sodass ich mehr Informationen zum Teilen habe.

Meiner Meinung nach ist der Hauptnachteil von SPA-Anwendungen die Suchmaschinenoptimierung (SEO), die sich nur auf Dashboard-Apps beschränkt. Darüber hinaus wird das Caching im Vergleich zu klassischen Lösungen viel schwieriger. Beispielsweise ist das Zwischenspeichern in ASP.NET extrem einfach. Aktivieren Sie einfach OutputCaching, und Sie sind zufrieden: Die gesamte HTML-Seite wird entsprechend der URL (oder anderen Parametern) zwischengespeichert. In SPA müssen Sie sich jedoch selbst um das Zwischenspeichern kümmern (indem Sie einige Lösungen wie den Cache der zweiten Ebene, das Zwischenspeichern von Vorlagen usw. verwenden).

28
Illidan

Ich möchte dafür eintreten, dass SPA das Beste für datengetriebene Anwendungen ist. Bei Google Mail dreht sich natürlich alles um Daten und ist daher ein guter Kandidat für ein SPA.

Wenn Ihre Seite jedoch hauptsächlich für die Anzeige bestimmt ist, z. B. eine Seite mit Nutzungsbedingungen, ist ein SPA völlig überfordert.

Ich denke, der Sweet Spot hat eine Site mit einer Mischung aus Seiten im SPA- und statischen/MVC-Stil, abhängig von der jeweiligen Seite.

Beispielsweise landet der Benutzer auf einer Site, die ich gerade baue, auf einer Standard-MVC-Indexseite. Wenn sie dann zur eigentlichen Anwendung wechseln, wird der SPA aufgerufen. Ein weiterer Vorteil ist, dass die Ladezeit des SPA nicht auf der Homepage, sondern auf der App-Seite steht. Die Ladezeit auf der Homepage kann für Erstnutzer der Website eine Ablenkung sein.

Dieses Szenario ähnelt der Verwendung von Flash. Nach einigen Jahren Erfahrung ging die Anzahl der reinen Flash-Sites aufgrund des Auslastungsfaktors auf nahezu null zurück. Als Seitenkomponente wird es jedoch weiterhin verwendet.

12
Greg Gum

Für Unternehmen wie Google, Amazon usw., deren Server im 24/7-Modus mit maximaler Kapazität laufen, bedeutet die Reduzierung des Datenverkehrs echtes Geld - weniger Hardware, weniger Energie, weniger Wartung. Die Verlagerung der CPU-Auslastung vom Server zum Client zahlt sich aus, und die SPAs glänzen. Die Vorteile überwiegen die Nachteile bei weitem. SPA oder nicht SPA hängt also stark vom Anwendungsfall ab.

Nur um einen anderen, wahrscheinlich für Webentwickler nicht so offensichtlichen Anwendungsfall für SPAs zu erwähnen: Ich bin derzeit auf der Suche nach einer Möglichkeit, GUIs in eingebetteten Systemen und einer browserbasierten Architektur zu implementieren. Traditionell gab es in eingebetteten Systemen nicht viele Möglichkeiten für Benutzeroberflächen - Java, Qt, wx usw. oder proprietäre kommerzielle Frameworks. Adobe hat vor einigen Jahren versucht, mit Flash auf den Markt zu kommen, scheint aber nicht so erfolgreich zu sein.

Heutzutage, da "eingebettete Systeme" vor einigen Jahren so leistungsfähig waren wie Großrechner, ist eine browserbasierte Benutzeroberfläche, die über REST) mit der Steuereinheit verbunden ist, eine mögliche Lösung Kostenlose Tools für die Benutzeroberfläche (z. B. 20 bis 30 US-Dollar pro verkaufter Lizenzgebühr plus 3000 bis 4000 US-Dollar pro Entwickler)

Für eine solche Architektur bietet SPA viele Vorteile - z. vertrauterer Entwicklungsansatz für Desktop-App-Entwickler, reduzierter Serverzugriff (in der Autoindustrie sind Benutzeroberfläche und System nicht einheitlich, wobei der Systemteil ein RT OS) hat).

Da der einzige Client der eingebaute Browser ist, zählen die genannten Nachteile wie JS-Verfügbarkeit, serverseitige Protokollierung, Sicherheit nicht mehr.

8

2. Mit SPA müssen wir keine zusätzlichen Anfragen an den Server stellen, um Seiten herunterzuladen.

Ich muss noch viel lernen, aber seit ich angefangen habe, über SPA zu lernen, liebe ich sie.

Dieser spezielle Punkt kann einen großen Unterschied machen.

In vielen Web-Apps, die kein SPA sind, werden Sie feststellen, dass sie weiterhin Inhalte abrufen und zu den Seiten hinzufügen, die Ajax-Anforderungen stellen. Ich denke also, dass SPA darüber hinaus geht, wenn man bedenkt: Was ist, wenn der Inhalt, der mit Ajax abgerufen und angezeigt wird, die ganze Seite ist? und nicht nur ein kleiner Teil einer Seite?

Lassen Sie mich ein Szenario vorstellen. Bedenken Sie, dass Sie 2 Seiten haben:

  1. eine Seite mit einer Liste von Produkten
  2. eine Seite zum Anzeigen der Details eines bestimmten Produkts

Bedenken Sie, dass Sie sich auf der Listenseite befinden. Dann klicken Sie auf ein Produkt, um die Details anzuzeigen. Die clientseitige App löst zwei Ajax-Anforderungen aus:

  1. eine Anfrage, um ein JSON-Objekt mit den Produktdetails zu erhalten
  2. eine Anfrage nach einer HTML-Vorlage, in die die Produktdetails eingefügt werden

Anschließend fügt die clientseitige App die Daten in die HTML-Vorlage ein und zeigt sie an.

Dann kehren Sie zur Liste zurück (diesbezüglich erfolgt keine Anfrage!) Und Sie öffnen ein anderes Produkt. Dieses Mal wird es nur eine Ajax-Anfrage geben, um die Details des Produkts zu erhalten. Die HTML-Vorlage wird identisch sein, sodass Sie sie nicht erneut herunterladen müssen.

Sie können sagen, dass Sie in einem Nicht-SPA nur eine Anfrage stellen, wenn Sie die Produktdetails öffnen. In diesem Szenario haben wir 2. Ja. Aber Sie erhalten den Gewinn aus einer Gesamtperspektive, wenn Sie über viele Seiten navigieren, wird die Anzahl der Anfragen geringer sein. Und die Daten, die zwischen dem Client und dem Server übertragen werden, werden ebenfalls geringer, da die HTML-Vorlagen wiederverwendet werden. Außerdem müssen Sie nicht bei jeder Anforderung alle CSS-, Bild- und Javascript-Dateien herunterladen, die auf allen Seiten vorhanden sind.

Angenommen, Ihre serverseitige Sprache ist Java. Wenn Sie die 2 Anforderungen analysieren, die ich erwähnt habe, lädt 1 Daten herunter (Sie müssen keine Ansichtsdatei laden und die Ansichts-Rendering-Engine aufrufen) und die anderen Downloads und die statische HTML-Vorlage, damit Sie einen HTTP-Webserver haben, der sie abrufen kann es direkt, ohne den Java Anwendungsserver aufrufen zu müssen, wird keine Berechnung durchgeführt!

Schließlich nutzen die großen Unternehmen SPA: Facebook, GMail, Amazon. Sie spielen nicht, sie haben die besten Ingenieure, die das alles studieren. Wenn Sie also die Vorteile nicht erkennen, können Sie ihnen zunächst vertrauen und hoffen, sie später zu entdecken.

Es ist jedoch wichtig, gute SPA-Designmuster zu verwenden. Sie können ein Framework wie AngularJS verwenden. Versuchen Sie nicht, ein SPA ohne gute Entwurfsmuster zu implementieren, da dies zu Problemen führen kann.

4
dam_js

In meiner Entwicklung habe ich zwei eindeutige Vorteile für die Verwendung eines SPA gefunden. Das heißt nicht, dass das Folgende in einer herkömmlichen Web-App nicht erreicht werden kann, nur dass ich einen inkrementellen Nutzen sehe, ohne zusätzliche Nachteile einzuführen.

  • Das Potenzial für weniger Serveranfragen beim Rendern neuer Inhalte ist nicht immer oder überhaupt keine HTTP-Serveranfrage für eine neue HTML-Seite. Aber ich sage Potenzial, weil neue Inhalte leicht einen Ajax-Aufruf erfordern könnten, um Daten abzurufen, aber diese Daten könnten inkrementell leichter sein als das selbst plus Markup, was einen Nettovorteil darstellt.

  • Die Fähigkeit, den "Staat" zu erhalten. Im einfachsten Fall legen Sie beim Aufrufen der App eine Variable fest, die anderen Komponenten während der gesamten Benutzererfahrung zur Verfügung steht, ohne sie weiterzugeben oder auf ein lokales Speichermuster festzulegen. Die intelligente Verwaltung dieser Fähigkeit ist jedoch der Schlüssel, um die Übersichtlichkeit des Bereichs auf höchster Ebene zu gewährleisten.

Abgesehen davon, dass JS erforderlich ist (was für Web-Apps nicht verrückt ist), sind andere festgestellte Nachteile meiner Meinung nach entweder nicht SPA-spezifisch oder können durch gute Gewohnheiten und Entwicklungsmuster gemildert werden.

2
JOP

Nachteile : Das Design und die anfängliche Entwicklung von SPA sind technisch komplex und können vermieden werden. Andere Gründe für die Nichtbenutzung dieses SPA können sein:

  • a) Sicherheit: Single Page Application ist im Vergleich zu herkömmlichen Seiten aufgrund von Cross Site Scripting (XSS) weniger sicher.
  • b) Speicherverlust: Ein Speicherverlust in JavaScript kann sogar dazu führen, dass leistungsfähige Computer langsamer werden. Da herkömmliche Websites zum Navigieren zwischen den Seiten anregen, werden Speicherlecks, die durch die vorherige Seite verursacht wurden, beinahe beseitigt und es bleiben weniger Rückstände zurück.
  • c) Der Client muss JavaScript aktivieren, damit SPA ausgeführt werden kann. In mehrseitigen Anwendungen kann JavaScript jedoch vollständig vermieden werden.
  • d) SPA wächst auf die optimale Größe, was zu langen Wartezeiten führt. ZB: Arbeiten in Google Mail mit langsamerer Verbindung.

Abgesehen von den oben genannten Einschränkungen bestehen weitere architektonische Einschränkungen im Verlust von Navigationsdaten, in der Protokollierung des Navigationsverlaufs im Browser und in Schwierigkeiten beim automatisierten Funktionstest mit Selen.

This Link erklärt die Vor- und Nachteile einer einseitigen Anwendung.

2
Vish

Versuchen Sie, die Verwendung eines SPA nicht in Betracht zu ziehen, ohne vorher festzulegen, wie Sie die Sicherheit und API-Stabilität auf der Serverseite behandeln. Dann werden Sie einige der wahren Vorteile sehen, die die Verwendung eines SPA mit sich bringt. Wenn Sie einen RESTful-Server verwenden, der aus Sicherheitsgründen OAUTH= 2.0 implementiert, werden zwei grundlegende Unterschiede zwischen den Bedenken erzielt, die Ihre Entwicklungs- und Wartungskosten senken können.

  1. Dies verschiebt die Sitzung (und deren Sicherheit) in das SPA und entlastet Ihren Server von all dem Overhead.
  2. Ihre APIs werden sowohl stabil als auch leicht erweiterbar.

Andeutung zu früher, aber nicht explizit gemacht; Wenn Sie Android & Apple) - Anwendungen bereitstellen möchten, schreiben Sie ein JavaScript - SPA, das von einem systemeigenen Aufruf umschlossen wird, um den Bildschirm in einem Browser zu hosten (Android oder Apple) macht die Pflege einer Apple Codebasis und einer Android Codebasis überflüssig.

1
Bill Lawrence

Ich verstehe, dass dies eine ältere Frage ist, aber ich möchte einen weiteren Nachteil von Single Page Applications hinzufügen:

Wenn Sie eine API erstellen, die Ergebnisse in einer Datensprache (z. B. XML oder JSON) und nicht in einer Formatierungssprache (z. B. HTML) zurückgibt, können Sie die Interoperabilität von Anwendungen verbessern, z. B. in B2B-Anwendungen. Eine solche Interoperabilität hat große Vorteile, ermöglicht es jedoch, Software zu schreiben, um Ihre Daten "abzubauen" (oder zu stehlen). Dieser besondere Nachteil ist allen APIs gemeinsam, die eine Datensprache verwenden, und nicht den SPAs im Allgemeinen (tatsächlich vermeidet ein SPA, das den Server nach vorgerendertem HTML fragt, dies, jedoch auf Kosten einer schlechten Trennung von Modell und Ansicht). Dieses durch diesen Nachteil bedingte Risiko kann durch verschiedene Maßnahmen wie Anforderungsbegrenzung und Verbindungsblockierung usw. gemindert werden.

0
magnus