Einzelseitenanwendung: Vor- und Nachteile [geschlossen]

Ich habe über SPA gelesen und es hat Vorteile. Ich finde die meisten von ihnen nicht überzeugend. Es gibt 3 Vorteile, die meine Zweifel wecken.

Frage: Können Sie als Anwalt von SPA auftreten und beweisen, dass ich in Bezug auf die ersten drei Aussagen falsch liege?

                              === ADVANTAGES ===

1. SPA eignet sich hervorragend für sehr reaktionsschnelle Websites:

Das serverseitige Rendern ist für alle Zwischenzustände schwer zu implementieren - kleine Ansichtszustände lassen sich nicht gut auf URLs abbilden.

Apps für einzelne Seiten zeichnen sich durch ihre Fähigkeit aus, einen beliebigen Teil der Benutzeroberfläche neu zu zeichnen, ohne dass ein Server-Roundtrip zum Abrufen von HTML erforderlich ist. Dies wird erreicht, indem die Daten von der Darstellung der Daten getrennt werden, indem eine Modellebene vorhanden ist, die Daten verarbeitet, und eine Ansichtsebene, die aus den Modellen liest.

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 Abfragen an den Server verwenden, um Seiten herunterzuladen.

Hah, und wie viele Seiten kann der 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.

3. Können andere Vorteile sein? Hören Sie nichts anderes ..

                            === DISADVANTAGES ===

1. Der Client muss Javascript aktivieren.
2. Nur ein Einstiegspunkt zur Site.
3. Sicherheit.

PS 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, etwas mehr über SPA zu lesen. Ich möchte nur Ihre Überlegungen dazu hören.

Schauen wir uns eine der beliebtesten SPA-Sites an, GMail.

1. SPA eignet sich hervorragend für sehr reaktionsschnelle Websites:

Das serverseitige Rendern ist nicht mehr so ​​schwierig wie früher mit einfachen Techniken wie dem Beibehalten eines #Hashs in der URL oder neuerdings HTML5pushState . Bei diesem Ansatz wird der genaue Status der Web-App in die Seiten-URL eingebettet. Wie in GMail wird der URL jedes Mal, wenn Sie eine E-Mail öffnen, ein spezielles Hash-Tag 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 wird direkt einer traditionelleren Abfragezeichenfolge zugeordnet. Der Unterschied besteht lediglich in der Ausführung. Mit HTML5 pushState () können Sie die #hashvollständig klassischen URLs entfernen und verwenden, 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 Abfragen an den Server verwenden, um Seiten herunterzuladen.

Die Anzahl der Seiten, die Benutzer während des Besuchs meiner Website herunterladen? wirklich, wie viele Mails manche lesen, wenn er / sie sein / ihr Mail-Konto eröffnet. Ich las> 50 auf einmal. Jetzt ist die Struktur 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 / Anmeldungen aufbewahren, die vollständig von der Struktur Ihrer Website abhängen. Nehmen Sie beispielsweise paytm.com. Wenn Sie beispielsweise ein Website-SPA erstellen, bedeutet dies nicht, dass Sie alle Endpunkte für alle öffnen Benutzer Ich meine, ich verwende Forms Auth mit meiner Spa-Website. - In dem wahrscheinlich am häufigsten verwendeten SPA-Framework Angular JS kann der Entwickler den gesamten HTML-Tempel von der Website laden, sodass dies abhängig von der Authentifizierungsstufe des Benutzers erfolgen kann. HTML vor dem Laden für alle Authentifizierungstypen ist nicht '

3. Kann es weitere Vorteile geben? Hören Sie 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, ist die Aufrechterhaltung des Zustands möglich. Sie können beliebig viele Einstiegspunkte haben, aber Sie sollten auf jeden Fall einen haben.
• Selbst in einem SPA-Benutzer muss nur darauf geachtet werden, welche Rechte er besitzt. Sie müssen nicht alles auf einmal injizieren. Das Laden von Diff-HTML-Vorlagen und asynchronem Javascript ist ebenfalls ein gültiger Bestandteil von SPA.

Vorteile, die mir einfallen, sind:

1. Das Rendern von HTML erfordert offensichtlich einige Ressourcen, jetzt tut dies jeder Benutzer, der Ihre Site besucht. Außerdem erfolgt das Rendern wichtiger Logiken jetzt nicht nur clientseitig, sondern auch serverseitig.
2. Datums- und Uhrzeitprobleme - Ich gebe dem Client nur die UTC-Zeit als voreingestelltes Format an und kümmere mich nicht einmal um die Zeitzonen, in denen Javascript damit umgehen soll. Dies ist ein großer Vorteil für den Fall, dass ich Zeitzonen basierend auf dem Standort erraten musste, der von der IP des Benutzers abgeleitet wurde.
3. Für mich ist der Status in einem SPA besser gepflegt, da Sie wissen, dass eine Variable vorhanden sein wird, sobald Sie sie festgelegt haben. Dies vermittelt das Gefühl, eher eine App als eine Webseite zu entwickeln. Dies hilft in der Regel sehr bei der Erstellung von Websites wie Foodpanda, Flipkart, Amazon. Denn wenn Sie keinen clientseitigen Status verwenden, verwenden Sie teure Sitzungen.
4. Websites sind sicherlich extrem reaktionsschnell - ich nehme ein extremes Beispiel für diesen Versuch, einen Taschenrechner in einer Nicht-SPA-Website zu erstellen (ich weiß, dass es seltsam ist).

Aktualisierungen aus Kommentaren

Es scheint nicht so, als würde jemand von Sockets und langen Abstimmungen sprechen. Wenn Sie sich von einem anderen Client abmelden, z. B. Mobile App, sollte sich Ihr Browser ebenfalls abmelden. Wenn Sie kein SPA verwenden, müssen Sie die Socket-Verbindung jedes Mal neu erstellen, wenn eine Umleitung erfolgt. Dies sollte auch mit 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) an diese native App senden und clientseitig verarbeiten, um sie zu rendern. Richtig? Mit dieser Behauptung erstellen 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 Kinderspiel. Dann stellt sich die Frage, ob Sie serverseitige Seiten nur für SEO-Vorteile und die Bequemlichkeit von gemeinsam nutzbaren / mit Lesezeichen versehenen URLs rendern möchten

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

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

Vorteile

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

Nachteile

• Leistungsüberwachung - Hände gebunden: Die meisten Leistungsüberwachungslösungen auf Browserebene, die ich gesehen habe, konzentrieren sich ausschließlich auf die Ladezeit von Seiten, z. B. Zeit bis zum ersten Byte, Zeit zum Erstellen von DOM, Netzwerk-Roundtrip für HTML, Onload-Ereignis usw. Aktualisieren der Seite Nachladung über AJAX würde nicht gemessen. Es gibt Lösungen, mit denen Sie Ihren Code instrumentieren können, um explizite Kennzahlen aufzuzeichnen, z. B. beim Klicken auf einen Link, Starten eines Timers, Beenden eines Timers nach dem Rendern der AJAX-Ergebnisse und Senden dieses Feedbacks. New Relic unterstützt beispielsweise diese Funktionalität. Durch die Verwendung eines SPA haben Sie sich an nur wenige mögliche Tools gebunden.
• Sicherheits- / Penetrationstests - Hände gebunden: Automatisierte Sicherheitsscans können Schwierigkeiten haben, Links zu erkennen, wenn Ihre gesamte Seite dynamisch von einem SPA-Framework erstellt wird. Es gibt wahrscheinlich Lösungen dafür, aber Sie haben sich wieder eingeschränkt.
• Bündelung: Es ist leicht, in eine Situation zu geraten, in der Sie beim ersten Laden der Seite den gesamten Code herunterladen, der für die gesamte Website erforderlich ist. Dies kann bei Verbindungen mit geringer Bandbreite eine schreckliche Leistung bringen. Sie können Ihre JavaScript- und CSS-Dateien bündeln, um zu versuchen, im Laufe der Zeit natürlichere Blöcke zu laden. Jetzt müssen Sie diese Zuordnung beibehalten und darauf achten, dass unbeabsichtigte Dateien über nicht realisierte Abhängigkeiten abgerufen werden (ist mir gerade passiert). Wieder lösbar, aber mit Kosten.
• Big Bang Refactoring: Wenn Sie eine größere architektonische Änderung vornehmen möchten, z. B. von einem Framework zu einem anderen wechseln, um das Risiko zu minimieren, ist es wünschenswert, inkrementelle Änderungen vorzunehmen. Beginnen Sie also mit der Verwendung des neuen, migrieren Sie auf einer bestimmten Basis, z. B. pro Seite, pro Feature usw., und löschen Sie das alte nachher. Mit der herkömmlichen mehrseitigen App können Sie eine Seite von Angular zu React wechseln und im nächsten Sprint eine andere Seite wechseln. Mit einem SPA ist alles oder nichts. Wenn Sie ändern möchten, müssen Sie die gesamte Anwendung auf einmal ändern.
• Komplexität der Navigation: Es gibt Tools, mit denen der Navigationskontext in SPAs wie history.js und Angular 2 beibehalten werden kann. Die meisten davon basieren entweder auf dem URL-Framework (#) oder der neueren Verlaufs-API. Wenn jede Seite eine separate Seite wäre, brauchen Sie nichts davon.
• Komplexität beim Herausfinden von Code: Wir betrachten Websites natürlich als Seiten. Eine mehrseitige App partitioniert normalerweise Code für Seite, was die Wartbarkeit erleichtert.

Ich erkenne wieder, dass jedes dieser Probleme um einen gewissen Preis lösbar ist. Aber irgendwann verbringen Sie Ihre ganze Zeit damit, Probleme zu lösen, die Sie eigentlich hätten vermeiden können. Es kommt auf die Vorteile zurück und wie wichtig sie für Sie sind.

Nachteile

1. Der Client muss Javascript aktivieren. Ja, dies ist ein klarer Nachteil von SPA. In meinem Fall weiß ich, dass ich von meinen Benutzern erwarten kann, dass JavaScript aktiviert ist. Wenn Sie nicht können, können Sie kein SPA durchführen. Dies entspricht dem Versuch, eine .NET-App auf einem Computer ohne installiertes .NET Framework bereitzustellen.

2. Nur ein Einstiegspunkt zur Site. Ich löse dieses Problem mit SammyJS . 2-3 Arbeitstage, um Ihr Routing richtig einzurichten, und die Benutzer können Deep-Link-Lesezeichen in Ihrer App erstellen, die ordnungsgemäß funktionieren. Ihr Server muss nur einen Endpunkt verfügbar machen - 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 tatsächlichen Eintrag in die Anwendung behandeln.

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" haben (das HATEOAS-Modell für die Verwendung von Hypertext zum Verknüpfen von Seiten). Es ist nur so, dass der Benutzer die Anforderungen eher als Ihr JavaScript stellt und dass die Ergebnisse eher in HTML als in JSON oder einem 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 Zugriff auf den gesamten Code hat, 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 Anfragen stellt Dinge, von denen der Client weiß, dass er Zugriff haben sollte, basierend auf einem 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 "Chattiness" Ihrer App. Wenn Sie es so gestalten, dass es die meisten Verarbeitungen auf dem Client abwickelt (schließlich der springende Punkt), wird die Anzahl der Anforderungen an den Server (siehe "Möglichkeiten für 503 Fehler, die Ihre Benutzererfahrung beeinträchtigen") drastisch reduziert. Tatsächlich ermöglicht ein SPA die vollständige Offline-Verarbeitung, was in einigen Situationen sehr groß 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 SPA nicht allein auf dieser Basis geltend.

3. Flexibilität in Ihrem UI-Design ist vielleicht der andere große Vorteil, den ich gefunden habe. Sobald ich meinen API definiert (mit einem SDK in JavaScript), konnte ich völlig mein Front-End mit umschreiben Null Auswirkungen auf den Server abgesehen von einigen statischen Ressourcen - Dateien. Versuchen Sie das mit einer traditionellen MVC-App! :) (Dies ist hilfreich, wenn Sie sich um Live-Bereitstellungen und die Versionskonsistenz Ihrer API sorgen müssen.)

Fazit: Wenn Sie eine Offline-Verarbeitung benötigen (oder zumindest möchten, dass Ihre Clients gelegentliche Serverausfälle überstehen können) - 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.

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

Während der Entwicklung von SPA werden Sie gezwungen sein, SEO-Probleme zu lösen, wahrscheinlich indem Sie Ihre gesamte Website nach dem Rendern rendern 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:

Seit ich diese Antwort vor einiger Zeit geschrieben habe, sammle ich viel mehr Erfahrung mit Single Page Apps (nämlich AngularJS 1.x) - daher habe ich mehr Informationen zum Teilen.

Meiner Meinung nach ist der Hauptnachteil von SPA-Anwendungen die Suchmaschinenoptimierung, sodass sie nur auf "Dashboard" -Anwendungen beschränkt sind. Darüber hinaus werden Sie mit dem Caching im Vergleich zu klassischen Lösungen viel schwierigere Zeiten haben. In ASP.NET ist das Caching beispielsweise extrem einfach - aktivieren Sie einfach OutputCaching und Sie sind gut: Die gesamte HTML-Seite wird gemäß der URL (oder anderen Parametern) zwischengespeichert. In SPA müssen Sie das Caching jedoch selbst durchführen (indem Sie einige Lösungen wie Cache der zweiten Ebene, Caching von Vorlagen usw. verwenden).

Ich möchte dafür eintreten, dass SPA am besten für datengesteuerte Anwendungen geeignet 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 zur Anzeige dient, z. B. eine Seite mit Nutzungsbedingungen, ist ein SPA völlig übertrieben.

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

Beispielsweise landet der Benutzer auf einer Site, die ich erstelle, auf einer Standard-MVC-Indexseite. Wenn sie dann zur eigentlichen Anwendung wechseln, wird das SPA aufgerufen. Ein weiterer Vorteil besteht darin, dass sich die Ladezeit des SPA nicht auf der Startseite, sondern auf der App-Seite befindet. Die Ladezeit auf der Startseite kann für Benutzer der ersten Website eine Ablenkung sein.

Dieses Szenario ähnelt der Verwendung von Flash. Nach einigen Jahren Erfahrung sank die Anzahl der Nur-Flash-Sites aufgrund des Auslastungsfaktors auf nahezu Null. Als Seitenkomponente wird sie jedoch weiterhin verwendet.

Für Unternehmen wie Google, Amazon usw., deren Server im 24/7-Modus mit maximaler Kapazität betrieben werden, 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 SPAs leuchten. Die Vorteile übergewichten Nachteile bei weitem. SPA oder nicht SPA hängt also stark vom Anwendungsfall ab.

Nur um einen anderen, wahrscheinlich nicht so offensichtlichen (für Webentwickler) Anwendungsfall für SPAs zu erwähnen: Ich suche derzeit nach einer Möglichkeit, GUIs in eingebetteten Systemen zu implementieren, und eine browserbasierte Architektur scheint mir ansprechend zu sein. Traditionell gab es nicht viele Möglichkeiten für Benutzeroberflächen in eingebetteten Systemen - Java, Qt, wx usw. oder kommerzielle Frameworks. Vor einigen Jahren hat Adobe 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 Mainframes, ist eine browserbasierte Benutzeroberfläche, die über REST mit der Steuereinheit verbunden ist, eine mögliche Lösung. Der Vorteil ist, dass die riesige Palette an Tools für die Benutzeroberfläche kostenlos ist. (zB Qt erfordern 20-30 $ pro verkaufter Einheit Lizenzgebühren plus 3000-4000 $ pro Entwickler)

Für eine solche Architektur bietet SPA viele Vorteile - z. B. einen bekannteren Entwicklungsansatz für Desktop-App-Entwickler, reduzierten Serverzugriff (in der Autoindustrie sind die Benutzeroberfläche und die Systemverwirrungen häufig separate Hardware, wobei der Systemteil über ein RT-Betriebssystem verfügt).

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

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

Ich muss noch viel lernen, aber seit ich angefangen habe, etwas ü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-Anfragen stellen. Ich denke also, dass SPA darüber hinaus geht, indem es überlegt: Was ist, wenn der Inhalt, der mit Ajax abgerufen und angezeigt werden soll, die gesamte 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 der Produkte
2. Eine Seite, auf der die Details eines bestimmten Produkts angezeigt werden

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

1. eine Anfrage, um ein JSON-Objekt mit den Produktdetails zu erhalten
2. eine Anfrage, um eine HTML-Vorlage zu erhalten, 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 (dies wird nicht angefordert!) Und öffnen ein anderes Produkt. Dieses Mal wird es nur eine Ajax-Anfrage geben, um die Details des Produkts zu erhalten. Die HTML-Vorlage ist dieselbe, sodass Sie sie nicht erneut herunterladen müssen.

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

Nehmen wir außerdem an, dass Ihre serverseitige Sprache Java ist. Wenn Sie die 2 von mir erwähnten Anforderungen analysieren, lädt 1 Daten herunter (Sie müssen keine Ansichtsdatei laden und die Ansichts-Rendering-Engine aufrufen) und die anderen Downloads und statischen HTML-Vorlagen, damit Sie einen HTTP-Webserver haben, der abgerufen werden 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 sehen, können Sie ihnen zunächst vertrauen und hoffen, sie später zu entdecken.

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

Nachteile : Technisch gesehen ist das Design und die anfängliche Entwicklung von SPA komplex und kann vermieden werden. Andere Gründe für die Nichtbenutzung dieses SPA können sein:

• a) Sicherheit: Die Anwendung einzelner Seiten 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 ein leistungsfähiger Computer langsamer wird. Da herkömmliche Websites zum Navigieren zwischen den Seiten anregen, wird jeder durch die vorherige Seite verursachte Speicherverlust fast bereinigt, sodass weniger Rückstände zurückbleiben.
• c) Der Client muss JavaScript aktivieren, damit SPA ausgeführt werden kann. In mehrseitigen Anwendungen kann JavaScript jedoch vollständig vermieden werden.
• d) Das SPA wächst auf die optimale Größe und verursacht lange Wartezeiten. Beispiel: Arbeiten an Google Mail mit langsamerer Verbindung.

Abgesehen von den oben genannten Einschränkungen sind Navigationsdatenverlust, Kein Protokoll des Navigationsverlaufs im Browser und Schwierigkeiten beim automatisierten Funktionstest mit Selen weitere architektonische Einschränkungen.

Dieser Link erläutert die Vor- und Nachteile einer Einzelseitenanwendung.

In meiner Entwicklung habe ich zwei deutliche 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 zusätzlichen Nutzen sehe, ohne zusätzliche Nachteile einzuführen.

• Das Potenzial für weniger Serveranforderungen, da das Rendern neuer Inhalte nicht immer oder sogar nie eine http-Serveranforderung für eine neue HTML-Seite ist. 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 bietet.

• Die Fähigkeit, "Zustand" aufrechtzuerhalten. Legen Sie im einfachsten Sinne beim Eintritt in die 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 den Bereich der obersten Ebene übersichtlich zu halten.

Abgesehen von der Anforderung von JS (was für Web-Apps keine verrückte Sache ist) sind andere festgestellte Nachteile meiner Meinung nach entweder nicht SPA-spezifisch oder können durch gute Gewohnheiten und Entwicklungsmuster gemindert werden.

Versuchen Sie nicht, ein SPA zu verwenden, ohne vorher zu definieren, wie Sie die Sicherheit und API-Stabilität auf der Serverseite angehen. Dann werden Sie einige der wahren Vorteile der Verwendung eines SPA sehen. Wenn Sie einen RESTful-Server verwenden, der aus Sicherheitsgründen OAUTH 2.0 implementiert, werden Sie zwei grundlegende Probleme lösen, die Ihre Entwicklungs- und Wartungskosten senken können.

1. Dadurch wird die Sitzung (und ihre Sicherheit) auf das SPA verschoben und Ihr Server von all dem Overhead entlastet.
2. Ihre APIs werden sowohl stabil als auch leicht erweiterbar.

Vorhin angedeutet, aber nicht explizit angegeben; Wenn Sie Android- und Apple-Anwendungen bereitstellen möchten, müssen Sie nicht mehr sowohl eine Apple-Codebasis als auch eine Android-Codebasis verwalten, indem Sie ein JavaScript-SPA schreiben, das von einem nativen Aufruf zum Hosten des Bildschirms in einem Browser (Android oder Apple) umschlossen wird.

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

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