Einzelseitenanwendung: Vor- und Nachteile [geschlossen]

203

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.

VB_
quelle
1
2. und 3. sind keine Probleme.
Wiktor Zychla
1
Ich schlage vor, dass Sie, anstatt nur über SPAs zu lesen, einige Zeit damit verbringen könnten, mit einem tatsächlichen Framework wie extjs zu spielen. Die Zeit, die dort vergeht, wird sich auszahlen und Sie können Ihre eigenen Fragen beantworten.
Wiktor Zychla
3
@WiktorZychla Ich arbeite an einem SPA-Projekt. Ich benutze JQuery + Backbone. Ich habe auch eine JSP-Site geschrieben. Ich kann diese Fragen nicht beantworten. Können Sie?
VB_
3
@VolodymyrBakhmatiuk: Das spielt keine Rolle. Was der Benutzer kompromittieren kann, ist die GUI, nicht die Daten, da die Daten auf der Serverseite geschützt werden.
Wiktor Zychla
4
Was ist, wenn diese Frage meinungsbasiert ist? Ich habe mich oft gefragt, warum und wann ich ein SPA schreiben soll. Es wäre hilfreich, wenn SO auch
Vor- und Nachteile zulassen würde

Antworten:

144

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

Parv Sharma
quelle
4
Gut, dass du dies zu einer Community-Wiki-Antwort gemacht hast :) Auch das sind großartige Punkte
Jason Sperske
@Parv Sharma erklären Sie bitte ausführlicher, warum die Aufrechterhaltung des Zustands mit SPA besser zu vereinbaren ist.
VB_
4
Mit SPA können Sie Seiten für die SEO-Optimierung nicht einfach indizieren.
Ankit_Shah55
2
@ Ankit_Shah55 Dies trifft möglicherweise nicht mehr zu (zumindest für Google, das sowieso den größten Teil des Marktanteils von Suchmaschinen besitzt). Siehe "Verwerfen unseres AJAX-Crawling-Schemas" von Google. Meines Wissens nach müssen Sie für Google nichts Besonderes mehr tun, um Ihr SPA zu indizieren. Ich denke, Sie müssen jedoch sicherstellen, dass Pushstate unterstützt wird, da ich glaube, dass Google keine Hash-Fragmente indiziert.
Kevin Wheeler
3
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
66

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.

Brandon
quelle
2
Ich denke, diese Antwort liefert sehr gültiges Feedback von jemandem, der tatsächlich ein großes komplexes System aufgebaut hat und die langfristigen Verluste erlebt hat, die SPA mit sich bringt (oder so aussieht)
DanielCuadra
4
Was ich aus dieser Antwort erhalte, ist, SPA zu vermeiden, wenn Sie etwas tun, das auch nur annähernd ernst ist.
IvanP
Ich denke, Sie haben uns einen sehr hilfreichen Überblick gegeben, statt nur zu antworten. Wirklich pragmatisch.
Hos Mercury
3
Genau. SPA sah großartig aus, als wir einen Proof of Concept machten. 3 Jahre später haben wir jedes in dieser Antwort erwähnte Problem gesehen und verbringen weiterhin viel Zeit damit, es zu lösen. Eine Änderung des Frameworks ist keine Option mehr und wir bleiben bei einem Framework, das die Entwicklung im Grunde gestoppt hat.
Qi Fan
1
Ich habe die letzten 4 Nachteile direkt erlebt. Ich habe eine 10K LOC-Webanwendung mit Angular, Bootstrap und PHP als Hauptakteuren mit etwa 5K Angular JS-Code erstellt. Es gibt einige wirklich nette Funktionen von Angular, aber an diesem Punkt wünschte ich mir wirklich, ich hätte gerade einen traditionellen seitenbasierten Ansatz verwendet und ich denke, dies hätte die Entwicklung der Site erheblich beschleunigt.
Zack Macomber
41

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.

Lars Kemmann
quelle
6
Ein weiterer Vorteil ist, dass ein SPA unter iOS als Lesezeichen ("Zum Startbildschirm hinzufügen") gespeichert und im Vollbildmodus geöffnet werden kann (vorausgesetzt, Sie haben das richtige Meta-Tag definiert ), sodass es sich wie eine native App anfühlt und nicht wie eine Website.
Strille
7
3. In der herkömmlichen MVC-App ist dies genauso einfach. Wenn Sie mit denselben Daten arbeiten, müssen Sie nur Änderungen im V-Teil (Ansicht) Ihrer App vornehmen. Dies sind normalerweise Vorlagen, CSS und JS.
Karantan
Kann eine SPA-Version von SO Links zu einzelnen Fragen haben, die geteilt werden können, oder welche Vor- und Nachteile würde dies mit sich bringen, beispielsweise in Bezug auf SEO (Suchbarkeit früherer Fragen über eine Suchmaschine)?
Selçuk
5
Die meisten SPA-Apps, die ich gesehen habe, sind gesprächiger als serverseitige Apps. Anstelle einer einzelnen Anforderung zum Abrufen von Daten erhalten Sie pro Seite mehr Anforderungen an den Server.
Matthew Whited
29

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).

Illidan
quelle
Ist es besser, wenn der Datenverkehr auf eine einzelne Seite weitergeleitet wird, anstatt auf mehrere Seiten verteilt zu sein?
SILENT
@SILENT - nicht sicher, aber da alle Seiten auf der gleichen Domain, denke ich nicht, dass es einen Unterschied geben sollte
Illidan
Ich verstehe das SEO-Argument nicht. Können Sie nicht einfach dieselben Routen in Ihrem SPA definieren, die auch serverseitig definiert sind, sodass Such-Bots Ihre Website problemlos crawlen können und gleichzeitig direkte URLs zu Ihren Inhalten erhalten. Und so können Sie zwei Sätze von Vorlagen pflegen, große Sache. Sie können versuchen, universelle Vorlagen zu verwenden, wenn dies ein Problem darstellt.
MarsAndBack
@MarsAndBack: Nicht sicher, über welche Server-Links Sie sprechen. Wenn Sie Sitemap meinen - dann ist es im Fall von SPA nutzlos: Suchmaschinen führen kein JavaScript aus (zumindest war dies vor einigen Jahren der Stand der Dinge), sondern laden nur HTML herunter und analysieren es. Selbst wenn Sie eine Sitemap vorbereiten, wird die Seite nicht korrekt erstellt.
Illidan
12

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.

Greg Gum
quelle
1
Nach vielen Jahren der Webentwicklung kann ich das bestätigen. Sie sollten sowohl Spa- als auch MVC-Apps miteinander mischen. Sie können weder noch eine Antwort haben. Ich hatte zuerst meine gesamte App als Spa und stellte fest, dass meine App von Google nicht korrekt aufgelistet wird. Also bin ich zu MPA gewechselt und benutze Spa nur in den benötigten Situationen. WordPress ist auch kein Spa und aus guten Gründen ein beliebter Rahmen.
Rudolf Schmidt
1
Dies ist auch mein Ansatz. Ich habe SPA als Hauptbereich für meine Benutzer, um die Suchergebnisse schnell zu durchsuchen, sei es auf einer Karte oder einer dynamischen Liste. Wenn Sie sich Details ansehen, werden diese als vom Server gerenderte Standardseiten geöffnet. Meine Routen funktionieren sowohl innerhalb des SPA als auch als Serverrouten beim ersten Laden. Ich habe Vorlagencode und Routencode dupliziert, aber es ist mir egal, es ist ein notwendiges Übel.
MarsAndBack
8

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.

Valentin Heinitz
quelle
1
Amazon macht sich keine allzu großen Sorgen um die Bandbreite oder die Anzahl der Anfragen. Jede Seite ist ungefähr 10 MB groß und über 200 Anfragen.
Matthew Whited
3

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.

dam_js
quelle
1
Facebook ist kein SPA, eigentlich ist es eine App im MPA-Stil, sie verwenden hier und da ReactJS für Kommentare, Chat usw. Instagram ist ein gutes Beispiel für die vollständige SPA-Seite mit aktiviertem PWA. Gleiches gilt für Amazon, Youtube sind beide MPA-Apps.
Peter Húbek
3

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.

Vish
quelle
12
Das ist falsch. a) XSS wirkt sich auf vom Server generierte Seiten genauso leicht aus wie auf dem Client generierte Dokumente. Ich würde mehr argumentieren, da es auf dem Client sehr einfache und effektive XSS-Minderungslösungen gibt. Wenn Sie XSS nicht zulassen möchten, interpretieren Sie vom Benutzer eingereichte Inhalte nicht als HTML. Jeder anständige Programmierer kann damit umgehen. Die Navigation ist mit allen verfügbaren Techniken (PushState, Hash-Routing usw.) einfach. AFT für ein ordnungsgemäß erstelltes SPA ist genau das gleiche wie für jede andere Webanwendung. Die Zusammenfassung Ihrer Antwort lautet, dass Sie nicht wissen, wie Sie für den Client erstellen sollen.
Jason Miller
@ JasonMiller: Stimme zu. Mir ist nur klar, dass die Zusammenfassung nicht den gesamten Kontext des gesamten Blogs ausmacht. Ich werde Änderungen daran vornehmen. Danke dir.
Vish
6
Die Punkte a und b sind vollständig ungültig. Beide haben mehr mit schlechter Programmierung zu tun als mit den Eigenschaften eines SPA, und beide sind mit einer herkömmlichen Website durchaus möglich. XSS-Schwachstellen können sich auf Ihre Site auswirken, auch wenn Sie keine JS-Zeile schreiben. Speicherlecks sind sowohl serverseitig als auch clientseitig möglich. Was Punkt c betrifft, so ist es für jeden, der Javascript heutzutage deaktiviert, wahrscheinlich, dass die Nutzung des Internets im Allgemeinen ein großes Problem darstellt. Dies ist meiner Meinung nach kein Problem.
Garryp
2

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.

JOP
quelle
1

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.

Bill Lawrence
quelle
0

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.

Magnus
quelle
2
1.) Keine API zu haben bedeutet nicht, dass HTML-Seiten nicht abgebaut werden können. 2.) Sie können den Missbrauch Ihrer API bis zu einem gewissen Grad verhindern. 3.) Mit einer API können Sie problemlos nicht nur Webseiten, sondern auch mobile Anwendungen darauf erstellen, was meiner Meinung nach die Nachteile erheblich überwiegt.
Honza Kalfus
1. Ich habe nicht gesagt, dass Nicht-API Data Mining verhindert. Ich habe gerade gesagt, dass eine API das Data Mining vereinfachen kann. 2. Darum ging es in meinem letzten Satz. 3. Eine API bietet viele Vorteile, und ich persönlich bevorzuge eine API / SPA-Kombination für die meisten Anwendungsfälle, auf die ich normalerweise stoße. Ich wollte der Liste jedoch nur einen einzigen Nachteil hinzufügen (den ich im Nachhinein eher als Kommentar als als vollständige Antwort hätte hinzufügen sollen).
Magnus
Entschuldigung, aber wenn ich nicht falsch verstanden habe, haben Sie nicht gesagt: "Eine solche Interoperabilität hat große Vorteile, ermöglicht es den Menschen jedoch, Software zu schreiben, um Ihre Daten" abzubauen "(oder zu stehlen)." Wenn ich Ihren Satz ein wenig ändern würde, könnte ich auch sagen, dass "Websites es Menschen ermöglichen, Software zu schreiben, um Ihre Daten" abzubauen "(oder zu stehlen)." und richtig sein. Jetzt sage ich nicht, dass Ihre Idee falsch ist, ich stimme zu, dass der Bergbau einfacher ist, ich sage nur, dass es nicht das ist, was Sie geschrieben haben;)
Honza Kalfus
Einverstanden. Es war nicht klar genug. In HTML eingebettete Daten können abgebaut werden. In JSON / XML / etc eingebettete Daten sind ebenfalls abbaubar, nur einfacher
Magnus