Progressive Enhancement vs. Single Page Apps

33

Ich bin gerade von einer Konferenz in Boston zurückgekommen, die An Event Apart heißt .

Ein sehr beliebtes Thema unter den Rednern war die Idee der fortschreitenden Verbesserung : Der Inhalt einer Website sollte im HTML-Format vorliegen, und JavaScript sollte nur zur Verbesserung des Verhaltens verwendet werden.

Die Argumente, die die Redner für eine schrittweise Verbesserung vorbrachten, waren sehr überzeugend. Dies ist nicht nur ein solides Muster für die Unterstützung älterer Browser und Geräte in einem Netzwerk mit geringer Bandbreite, sondern HTML schlägt auch viel eleganter fehl als JavaScript (dh Markups, die nicht unterstützt werden, werden nur ignoriert, wenn ein Browser während der Ausführung Ihres Browsers eine Ausnahme auslöst Drehbuch - du bist abgespritzt).

Jeremy Keith hielt darüber einen besonders aufschlussreichen Vortrag.

Aber was ist mit einseitigen Web-Apps wie Backbone und Angular? Das gesamte Design hinter diesen Frameworks scheint den Entwickler dazu zu bringen, Inhalte aus dem HTML-Code in eine Art JSON-API zu verschieben.

Ich kann nicht scheinen, diese zwei Entwurfsmuster zu gelieren: progressive Verbesserung gegen einzelne Seite Netz apps. Gibt es Fälle, in denen einer besser ist als der andere? Oder handelt es sich nicht einmal um antagonistische Technologien, und mir fehlt hier etwas mit meinem mentalen Modell?

— SeanPlusPlus
quelle

Sie haben zwei verschiedene Anwendungsfälle. Ja, es gibt Überschneidungen, wenn der Server das schwere Heben ausführt.

— BobDalgleish

5

Ich denke, es ist fair zu sagen, dass die Browseranforderungen für Einzelseitenanwendungen strenger sind als die für "normale" Webanwendungen.

— Robert Harvey

3

Sie sollten Jeremy Keith bitten, Ihnen ein Beispiel aus der Praxis zu geben, in dem progressive Verbesserungen die Mühe wert sind, 1-10% der Internetnutzer zufrieden zu stellen, und die Daten von 90% der Nutzer fragen, ob sie sich tatsächlich für progressive Verbesserungen interessieren oder ob sie zufrieden sind Wenn sie die Website mit IE 5.0 oder ohne Javascript besuchen können

— kirie

1

Wenn die Art von Leuten, die JS / images / etc deaktivieren, nicht zu Ihrer Kernzielgruppe gehört, gibt es keinen gültigen Geschäftsgrund, um Progressive Enhancement zu betreiben.

— Graham

1

Unterstützung für "Geräte in einem Netzwerk mit geringer Bandbreite" ist eigentlich ein Argument für SPA, nicht dagegen! Im SPA stellen Sie nur eine große Anfrage, ohne JS haben Sie es jedes Mal!

— Dmitri Zaitsev

21

Es scheint mir, dass einseitige Apps eine Grenze im Sand der fortschreitenden Verbesserung ziehen. Bevor wir versuchen, die Tatsache zu umgehen, dass Implementierungen und Funktionen zwischen den Browsern jahrzehntelang variieren, gehen die SPAs davon aus, dass es eine bestimmte Basis gibt, auf die sich die meisten Besucher einer bestimmten Website einig sind. Ich glaube nicht, dass die beiden uneins sind. Sie können nach dem Start des SPAs weiterhin schrittweise Verbesserungen vornehmen, z. B. mit einem <video>Tag beginnen und dann Ihren eigenen funktionsreichen Player darüber legen.

Dann gibt es Besucher mit deaktiviertem Scripting, die aber wissen, worauf sie sich einlassen. Ich verstehe nicht, warum Entwickler sich für diese Besucher nach hinten beugen sollten, abgesehen von dem Hinweis "Sie benötigen Skripte für diese Site". Wenn wir das zulassen, warum nicht auch für Besucher mit deaktiviertem CSS? Wie wäre es mit deaktivierten Bildern? Dies sind die wichtigsten Webtechnologien. Sie sollten nicht damit rechnen, ein voll funktionsfähiges Web-Erlebnis zu haben, wenn sie Teile auswählen.

Um sicherzustellen, dass ich nicht ohne Autoanalogie davonkomme, sollte ich nicht erwarten, dass mein Auto funktioniert, wenn ich feststelle, dass mir bestimmte Funktionen nicht gefallen. Ich könnte den Bauingenieuren sagen: "Ich habe meine Scheinwerfer deaktiviert. Bitte stellen Sie sicher, dass alle drei Meter Straßenbeleuchtung installiert ist, wenn ich sie besuche." Ohne Scheinwerfer würde mein Auto die meiste Zeit funktionieren, aber einige Orte kann ich nicht besuchen.

— Collin Allen
quelle

3

I don't see why developers should bend over backwards for those visitors. Wenn in Ihrem Vertrag festgelegt ist, dass Sie eine barrierefreie Version Ihrer Website bereitstellen müssen, ist die Verwendung eines SPA möglicherweise schwieriger. Was ist auch mit SEO?

— Simon Bergot

7

@ Simon: Sie können auch ein SPA zugänglich machen (siehe zB stackoverflow.com/questions/15318661/… ). Ebenso für SEO (wenn SEO wichtig ist, was von der App abhängt).

— sleske

2

Einige Ihrer Analogien sind ein bisschen wie ein Strohmann. Das Deaktivieren von Javascript hat einen Sicherheitszweck. Es ist schwer zu behaupten, dass das Hinzufügen von Scheinwerfern zu einer Pflege die Sicherheit beeinträchtigt.

— Robert Harvey

1

Richtig, das Deaktivieren von Skripten bietet Sicherheitsvorteile. Für die meisten Besucher lohnt sich die zusätzliche Sicherheit nicht. Ohne Skripte funktioniert Facebook nicht, LinkedIn bricht ab, Pinterest bricht ab, Instagram lädt eine leere Seite usw. Wenn die Hauptakteure dies wünschen, kann es auch Ihr SPA.

— Collin Allen

Nur wenn Sie FB und LinkedIn kennen, gibt es keinen guten Grund für diese Websites, ohne JS zu brechen, außer um Entwickler zu beruhigen, die sich nicht anstrengen möchten, eine akzeptabel funktionierende Website zu erstellen (oder Benutzer dazu zu zwingen, weniger sichere Surfpraktiken zu akzeptieren, die profitieren können). Wenn es sich um vollwertige Webanwendungen wie Plunker handelte, haben Sie vielleicht einen Punkt, aber die meisten "Webanwendungen" sind nur "Anwendungen" in dem Sinne, dass sie auf einer Art Framework basieren. In Bezug auf die Nutzung handelt es sich lediglich um Websites mit mehr Schnickschnack als früher.

— Dissident Wut

6

SPA ist am vorteilhaftesten, wenn Sie eine Anwendung erstellen, die nicht dem klassischen Anforderungs- / Antwortseitenmodell entspricht. Es gibt einen aktuellen Trend, bei dem reguläre Websites als SPA geschrieben werden, auch wenn sie genau in den Anforderungs- / Antwortzyklus des Webs passen. Diese Websites implementieren einen Webbrowser mit viel mehr Fehlern und weniger Funktionen nur unzureichend neu.

Die Idee der fortschreitenden Verbesserung und des SPA schließt sich für diese dummen, einseitigen Anwendungswebsites nicht gegenseitig aus. Sie benötigen lediglich das Javascript, um eine Inhaltsverhandlung durchzuführen (z. B. Header akzeptieren), damit sie eine JSON-Ressource erhalten, mit der sich das Javascript im SPA selbst rendern kann, anstatt zuvor gerenderte HTML-Seiten. Die Probleme mit dieser Art von Website-SPAs liegen auf der Hand. Sie müssen das Rendering der Website sowohl auf dem Server als auch auf dem Client doppelt implementieren.

Für echte Webanwendungen, dh solche, die wirklich ein SPA sein müssen, da sie nicht in das standardmäßige Anforderungs- / Antwortmuster passen. Progressive Enhancement ist für echte Anwendungen viel schwieriger, da sie eigentlich nur einen Browser als Technologieplattform zum portablen Schreiben einer Anwendung verwenden. Skriptsprache ist ein wesentlicher Bestandteil einer echten Webanwendung, nicht nur eine, die für Verbesserungen optional blockiert werden kann. Einige progressive Verbesserungstechniken können zwar noch funktionieren (z. B. Ersetzen von Flash-Video / Audio durch <video>/ <audio>tag), für echte Webanwendungen ist jedoch JavaScript als Basis erforderlich.

— Lüge Ryan
quelle

+1, aber es ist nicht immer leicht zu entscheiden, ob etwas "wirklich" ein SPA erfordert. Beispiel: Geschäftsanwendungen, bei denen es sich hauptsächlich um Dateneingaben handelt und die in den Formularen unterschiedlich komplex sind. Wenn die meisten Formulare einfach sind, ist ein SPA nicht "wirklich" erforderlich, sodass immer noch Spannungen zwischen SPA- und Nicht-SPA-Lösungen bestehen.

— sinelaw

@sinelaw: Die meisten Geschäftsanwendungen sollten im Allgemeinen kein SPA sein. Es gibt ein paar Ausnahmen, zB Tabellenkalkulation, Textverarbeitung, aber das sind die ungeraden. Indikatoren, für die Sie ein SPA benötigen: Wenn Sie Daten vom Server auf den Client übertragen müssen, nicht nur für ein oder zwei Benachrichtigungen, sondern als wesentliches Element der Anwendung, z. B. Spiel, Bestandsverfolgung, Chat-App. wenn Ihre Anwendung kein vernünftiges Konzept einer "Seite" aufweist oder das Konzept einer "Seite" in der App vollständig verzerrt ist, z. B. Office-Anwendungen. Geschäftsanwendungen, die hauptsächlich auf Formularen ausgeführt werden, bleiben besser als Nicht-SPA-Anwendungen.

— Lie Ryan

Zustimmen. Ein weiterer Indikator für ein SPA: Wenn die Entwicklung eines SPA billiger ist als die Entwicklung einer "klassischen" Website. Geschäftsanwendungen, die sich an eine bestimmte Zielgruppe richten, können manchmal Anforderungen wie "Verwendung eines modernen Browsers" auferlegen, sodass eine fortschreitende Verbesserung nur einen geringen Nutzen bringt.

— sinelaw

@sinelaw: Das Erstellen eines SPA ist fast nie billiger als das Entwickeln mehrseitiger Websites. vor allem, wenn Sie ältere Browser sowieso nicht bedienen.

— Lie Ryan

Wenn Ihr Team aus SPA-Experten besteht, die wenig Erfahrung mit serverzentrierten Projekten haben, ist dies günstiger.

— sinelaw

2

Ich glaube, dass Web-Apps für einzelne Seiten und die fortschreitende Verbesserung beinahe Gegenspieler sind. Wenn der HTML-Code auf dem Client anhand von Daten berechnet wird, die von einer JSON-API abgerufen wurden, kann er sich kaum ordnungsgemäß verschlechtern. Es kann jedoch eine reichhaltigere und angenehmere Benutzeroberfläche bieten.

Sie können einen Bot einrichten, der Ihre Anwendung crawlt und eine statische Version speichert. Diese Technik kann verwendet werden, um HTML für Browser ohne Javascript bereitzustellen (wird von Blinden oder Suchmaschinen-Bots verwendet). Da es sich um eine Investition handelt, kommt es wirklich auf Ihre Anforderungen an.

Erstellen Sie eine HR-Management-Web-App für ein bestimmtes Unternehmen? Sie brauchen keinen würdevollen Abbau, und ein SPA ist möglicherweise einfacher zu bauen. Das Unternehmen erzwingt möglicherweise die Verwendung eines bestimmten Browsers, sodass Sie möglicherweise weniger Tests durchführen müssen.

Erstellen Sie eine öffentliche Website für eine Verknüpfung mit den Anforderungen an die Barrierefreiheit und die Sichtbarkeit von Suchmaschinen? Dann überlegen Sie, ob Sie den HTML-Code auf Ihrem Server erstellen möchten. Oder machen Sie ein SPA mit einer statischen Version, abhängig von Ihrem Budget.

— Simon Bergot
quelle

1

Ich denke, es hängt davon ab, wie weit Sie mit Progressive Enhancement gehen möchten - es ist eher ein Designparadigma als ein hartes Regelwerk.

Wenn Sie ein SPA-Framework verwenden, ist es meiner Meinung nach eine Selbstverständlichkeit, Javascript zuzulassen. Das Javascript, das Sie schreiben, um Ihre Seite zu verbessern, muss jedoch intelligent genug sein, um mit jedem HTML-Code umzugehen, den das Framework erstellen kann.

Sie können auch von anderen PE-Techniken profitieren, z. B. von den neuesten CSS-Funktionen für eine neuere Browser-Version oder der Verschlechterung von HTML5 zu HTML4.

— Philicomus
quelle

1

Ein Teil der fortschreitenden Verbesserung ist, dass grundlegende Inhalte ohne Javascript verfügbar sein sollten. Ich bin mir nicht sicher, wie ich ein SPA ohne Javascript schreiben soll.

— Alan Shutko

@ AlanShutko Vielleicht mit iframes. Mehrere Seiten, aber technisch gesehen ändert sich die URL nicht ...;)

— Izkata

1

Ja, ich denke, ich habe mehr über HTML 5 als über HTML 4 nachgedacht und über Dinge wie browserspezifisches CSS (z. B. möchten Sie vielleicht eine kürzlich implementierte Funktion verwenden, die nur in der neuesten Version von Chrome verfügbar ist, sich aber in eine weiter verschlechtert) primitive Steuerung in älteren Browsern). In einem SPA wäre es schwierig, auf Javascript zu verzichten, aber das ist nur ein Teil des Konzepts der progressiven Verbesserung.

— Philicomus

Progressive Enhancement kann so einfach sein wie die Verwendung von css3, wenn es zum Abrunden von Ecken verfügbar ist. Die Grundidee hat nichts mit JavaScript zu tun.

— Daniel Little

1

Progressive Enhancement und eine Single Page App können nebeneinander existieren. Die beiden überzeugendsten Argumente, die ich für das Erstellen von Apps auf diese Weise gehört habe, sind:

Fehlertoleranz in Situationen, in denen die HTML-Datei vollständig heruntergeladen wird, auf die verwiesen wird, der vollständige Download der Skripte jedoch fehlschlägt, da die Netzwerkkonnektivität ein- und ausfällt (in mobilen Netzwerken möglich)
Potenzial für eine verbesserte wahrgenommene Leistung beim ersten Laden der Seite (durch Verkürzen der Startrenderzeiten)

Serverseitiges Rendering (nicht nur aus SEO-Gründen für Benutzer) und „Cut-the-Mustard“ sind zwei Techniken, die dazu beitragen können, fortschreitend verbesserte Single Page Apps mit modernen clientseitigen JS-Frameworks zu erstellen.

Einige clientseitige JS-Frameworks sind einfacher für die Arbeit mit serverseitigem Rendering als andere ( beachten Sie, dass einige serverseitige Rendering-Lösungen und Framework-Kombinationen keine funktionierenden SPAs erzeugen, da die vom Server gerenderte Seite nur für den Suchmaschinenverbrauch gedacht ist, nicht für das Ende -Benutzer ).

Zum Zeitpunkt des Schreibens sind React.js und Ember (mit dem kommenden FastBoot) die beiden, von denen ich weiß, dass sie das serverseitige Rendern zu einem erstklassigen Bürger machen oder versuchen; Die serverseitig gerenderte Seite ist nach wie vor ein funktionierendes SPA, wenn sie im Client-Browser analysiert wird.

— Eliot Sykes
quelle

0

Ich bin der Ansicht, dass die reduzierte Seitenlast für Server und das Netzwerk wahrscheinlich ganz gut ist. Ich würde gerne mehr SPAs sehen, die richtig eingesetzt werden.

Ich bin jedoch nicht der Ansicht, dass dies zwei Dinge erfordert:

1) Richten Sie alle Ihre Links beim ersten Laden als Standard-Anforderungs- / Antwort-Links ein. Lassen Sie Ihr SPA-Framework / Ihre SPA-Bibliothek diese dann durch eine aktualisierte (interaktive) Version ersetzen, sobald der Browser geladen ist und die JS-Engine feststellt, dass SPA-Unterstützung verfügbar ist. Dies ist wirklich eine fortschreitende Verbesserung. Der JS wird über die vorhandene HTML-Website geladen. Dies ist besser für Suchmaschinen, Hilfstechnologien und ältere Browser.

und

2) Der Server muss auf Routen wie / foo / bar / json und foo / bar reagieren, indem er das richtige Format bereitstellt. Wenn Sie alles in Layouts und Teilansichten verpacken, um die erste Seite zu erhalten, sollten Sie in der Lage sein, alles über Layouts und Teilansichten für die zweite und die folgenden Seiten zu erhalten.

Hier gibt es einiges an Arbeit. Zugegeben, aber wenn Sie die Kontrolle über den gesamten Stack haben, werden beide Technologien ausgeglichen.

— Crispen Smith
quelle