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 ===
- Der Client muss Javascript aktivieren.
- Nur ein Einstiegspunkt zur Site.
- 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.
Antworten:
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 HTML5
pushState
. 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#hash
vollstä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 ..
Vorteile, die mir einfallen, sind:
Aktualisierungen aus Kommentaren
quelle
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
Nachteile
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.
quelle
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
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 .
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.
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.
quelle
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).
quelle
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.
quelle
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.
quelle
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:
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:
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.
quelle
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:
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.
quelle
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.
quelle
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.
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.
quelle
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.
quelle