Auswählen zwischen herkömmlichen Web-Apps und Einzelseiten-Apps (SPAs)

"Atwoods Gesetz: Jede Anwendung, die in JavaScript geschrieben werden kann, wird schließlich in JavaScript geschrieben."
- Jeff Atwood

Es gibt zwei allgemeine Ansätze zum Erstellen von Webanwendungen heute: herkömmliche Webanwendungen, die die meisten Anwendungslogik auf dem Server ausführen, und Einzelseitenanwendungen (Single-Page Applications, SPAs), die den größten Teil der Benutzeroberflächenlogik in einem Webbrowser ausführen und mit dem Webserver in erster Linie mit Web-APIs kommunizieren. Ein Hybridansatz ist ebenfalls möglich, wobei das einfachste darin besteht, eine oder mehrere umfangreiche SPA-ähnliche Teilapplikationen innerhalb einer größeren, traditionellen Webanwendung zu hosten.

Verwenden Sie herkömmliche Webanwendungen in folgenden Fällen:

• Die clientseitigen Anforderungen Ihrer Anwendung sind einfach oder schreibgeschützt.

• Ihre Anwendung muss in Browsern ohne JavaScript-Unterstützung funktionieren.

• Ihre Anwendung ist öffentlich zugänglich und profitiert von der Suche und Empfehlung der Suchmaschine.

Verwenden Sie eine SPA in folgenden Fällen:

• Ihre Anwendung muss eine umfangreiche Benutzeroberfläche mit vielen Features verfügbar machen.

• Ihr Team ist mit JavaScript, TypeScript oder BlazorWebAssembly Entwicklung vertraut.

• Ihre Anwendung muss bereits eine API für andere (interne oder öffentliche) Clients verfügbar machen.

Darüber hinaus erfordern SPA-Frameworks eine größere Architektur- und Sicherheitskompetenz. Sie erfahren eine höhere Abwanderungsrate aufgrund häufiger Updates und neuer Clientframeworks im Vergleich zu herkömmlichen Webanwendungen. Das Konfigurieren automatisierter Build- und Bereitstellungsprozesse und die Verwendung von Bereitstellungsoptionen wie Containern ist mit SPA-Anwendungen möglicherweise schwieriger als herkömmliche Web-Apps.

Verbesserungen der Benutzererfahrung, die durch den SPA-Ansatz möglich gemacht werden, müssen gegen diese Überlegungen abgewogen werden.

Blazor

ASP.NET Core enthält ein Modell zum Erstellen von umfangreichen, interaktiven und komponierbaren Benutzeroberflächen, das Blazor genannt wird. Blazor Die serverseitige Technologie ermöglicht es Entwicklern, die Benutzeroberfläche mit C# und Razor auf dem Server zu erstellen und ermöglicht die interaktive Verbindung mit dem Browser in Echtzeit mithilfe einer persistenten SignalR-Verbindung. Blazor WebAssembly führt eine weitere Option für Blazor Apps ein, mit der sie im Browser unter Verwendung von WebAssembly ausgeführt werden können. Weil es sich um echten .NET-Code handelt, der auf WebAssembly ausgeführt wird, können Sie Code und Bibliotheken aus serverseitigen Teilen Ihrer Anwendung wiederverwenden.

Blazor bietet eine neue, dritte Möglichkeit, bei der Auswertung zu berücksichtigen, ob eine rein vom Server gerenderte Webanwendung oder eine SPA erstellt werden soll. Sie können umfangreiche Funktionen, die SPA-ähnliche clientseitige Verhaltensweisen bieten, mit Blazor erstellen, ohne dass eine erhebliche JavaScript-Entwicklung erforderlich ist. Blazor Anwendungen können APIs aufrufen, um Daten anzufordern oder serverseitige Vorgänge auszuführen. Sie können bei Bedarf mit JavaScript zusammenarbeiten, um JavaScript-Bibliotheken und -Frameworks nutzen zu können.

Erwägen Sie die Erstellung Ihrer Webanwendung mit Blazor in den folgenden Fällen:

• Ihre Anwendung muss eine umfassende Benutzeroberfläche verfügbar machen.

• Ihr Team ist mit der .NET-Entwicklung besser vertraut als mit der Entwicklung von JavaScript oder TypeScript

Wenn Sie über eine vorhandene Webanwendung verfügen, die Sie für die Migration zu .NET Core oder das neueste .NET in Betracht ziehen, sollten Sie das kostenlose E-Book für Web Forms-Entwickler überprüfen, um festzustellen, Blazor ob es sinnvoll ist, sie zu Blazormigrieren.

Weitere Informationen zu Blazor finden Sie unter Erste Schritte mit Blazor.

Gründe für die Auswahl herkömmlicher Web-Apps

Der folgende Abschnitt enthält eine ausführlichere Erläuterung der zuvor angegebenen Gründe für die Auswahl herkömmlicher Webanwendungen.

Ihre Anwendung verfügt über einfache, möglicherweise schreibgeschützte, clientseitige Anforderungen

Viele Webanwendungen werden von der überwiegenden Mehrheit ihrer Benutzer hauptsächlich nur zum Lesen genutzt. Schreibgeschützte (oder überwiegend schreibgeschützte) Anwendungen sind tendenziell viel einfacher als Anwendungen, die eine große Menge von Zuständen verwalten und bearbeiten. Beispielsweise kann eine Suchmaschine aus einem einzigen Einstiegspunkt mit einem Textfeld und einer zweiten Seite zum Anzeigen von Suchergebnissen bestehen. Anonyme Benutzer können problemlos Anforderungen stellen, und es gibt wenig Bedarf an clientseitiger Logik. Ebenso besteht die öffentlich zugängliche Anwendung eines Blog- oder Inhaltsverwaltungssystems in der Regel hauptsächlich aus Inhalten mit wenig clientseitigem Verhalten. Solche Anwendungen werden einfach als herkömmliche serverbasierte Webanwendungen erstellt, die Logik auf dem Webserver ausführen und HTML rendern, die im Browser angezeigt werden. Die Tatsache, dass jede eindeutige Seite der Website über eine eigene URL verfügt, die von Suchmaschinen mit Lesezeichen versehen und indiziert werden kann (standardmäßig, ohne diese Funktionalität als separates Feature der Anwendung hinzufügen zu müssen) ist auch in solchen Szenarien ein klarer Vorteil.

Ihre Anwendung muss in Browsern ohne JavaScript-Unterstützung funktionieren.

Webanwendungen, die in Browsern mit eingeschränkter oder ohne JavaScript-Unterstützung funktionieren müssen, sollten mit herkömmlichen Web App-Workflows geschrieben werden (oder zumindest in der Lage sein, auf ein solches Verhalten zurückzugreifen). SPAs erfordern clientseitiges JavaScript, um funktionieren zu können; Wenn sie nicht verfügbar ist, sind SPAs keine gute Wahl.

Ihr Team ist mit JavaScript- oder TypeScript-Entwicklungstechniken nicht vertraut.

Wenn Ihr Team mit JavaScript oder TypeScript nicht vertraut ist, aber mit der serverseitigen Webanwendungsentwicklung vertraut ist, können sie wahrscheinlich eine herkömmliche Web-App schneller als eine SPA bereitstellen. Es sei denn, das Ziel ist das Programmieren von SPAs oder die Benutzererfahrung, die ein SPA bietet, ist erforderlich, sind traditionelle Web-Apps eine produktivere Wahl für Teams, die bereits mit deren Erstellung vertraut sind.

Wann man SPAs wählen sollte

Im folgenden Abschnitt finden Sie eine ausführlichere Erläuterung, wann Sie einen Single Page Applications-Entwicklungsstil für Ihre Web-App auswählen.

Ihre Anwendung muss eine umfangreiche Benutzeroberfläche mit vielen Features verfügbar machen.

SPAs können umfangreiche clientseitige Funktionen unterstützen, die kein erneutes Laden der Seite erfordern, wenn Benutzer Aktionen ausführen oder zwischen Bereichen der App navigieren. SPAs können schneller geladen werden, das Abrufen von Daten erfolgt im Hintergrund, und einzelne Benutzeraktionen sind reaktionsfähiger, da ganzseitiges Neuladen selten ist. SPAs können inkrementelle Updates unterstützen und teilweise ausgefüllte Formulare oder Dokumente speichern, ohne dass der Benutzer auf eine Schaltfläche klicken muss, um ein Formular zu senden. SPAs können komplexe clientseitige Funktionen unterstützen, wie z. B. Drag-and-Drop, und dies deutlich besser als herkömmliche Anwendungen. SPAs können so konzipiert werden, dass sie in einem getrennten Modus ausgeführt werden und Aktualisierungen für ein clientseitiges Modell vornehmen, das schließlich wieder mit dem Server synchronisiert wird, sobald eine Verbindung erneut hergestellt wurde. Wählen Sie eine SPA-Formatanwendung aus, wenn die Anforderungen Ihrer App umfangreiche Funktionen enthalten, die über das typische HTML-Formular hinausgeht.

Häufig müssen SPAs Features implementieren, die in herkömmliche Web-Apps integriert sind, z. B. das Anzeigen einer aussagekräftigen URL in der Adressleiste, die den aktuellen Vorgang widerspiegelt (und Benutzern das Lesezeichen oder Deep-Link zu dieser URL ermöglicht, zu dieser URL zurückzukehren). SPAs sollten es Benutzern auch ermöglichen, die Schaltflächen "Zurück" und "Vorwärts" des Browsers mit Ergebnissen zu verwenden, die sie nicht überraschen.

Ihr Team ist mit der Entwicklung von JavaScript und/oder TypeScript vertraut.

Das Schreiben von SPAs erfordert Kenntnisse mit JavaScript und/oder TypeScript und clientseitigen Programmiertechniken und Bibliotheken. Ihr Team sollte mit einem SPA-Framework wie Angular kompetent modernes JavaScript schreiben.

Referenzen – SPA Frameworks

• Angular: https://angular.io
• React: https://reactjs.org/
• Vue.js: https://vuejs.org/

Ihre Anwendung muss bereits eine API für andere (interne oder öffentliche) Clients verfügbar machen.

Wenn Sie bereits eine Web-API für die Verwendung durch andere Clients unterstützen, ist möglicherweise weniger Aufwand erforderlich, um eine SPA-Implementierung zu erstellen, die diese APIs nutzt, anstatt die Logik in serverseitiger Form zu reproduzieren. SPAs verwenden umfangreiche Web-APIs zum Abfragen und Aktualisieren von Daten, wenn Benutzer mit der Anwendung interagieren.

Wann zu wählen Blazor

Der folgende Abschnitt enthält eine ausführlichere Erläuterung, wann Sie Blazor für Ihre Web-App auswählen sollten.

Ihre Anwendung muss eine umfassende Benutzeroberfläche verfügbar machen.

Wie javaScript-basierte SPAs können Anwendungen umfangreiches Clientverhalten unterstützen, Blazor ohne dass Seiten neu geladen werden müssen. Diese Anwendungen sind reaktionsfähiger für Benutzer und rufen nur die Daten (oder HTML) ab, die erforderlich sind, um auf eine bestimmte Benutzerinteraktion zu reagieren. Wenn korrekt konfiguriert, können serverseitige Blazor Apps mit minimalen Änderungen als clientseitige Blazor Apps ausgeführt werden, sobald dieses Feature unterstützt wird.

Ihr Team ist mit der .NET-Entwicklung besser vertraut als mit der Entwicklung von JavaScript oder TypeScript

Viele Entwickler sind mit .NET und Razor produktiver als mit clientseitigen Sprachen wie JavaScript oder TypeScript. Da die serverseitige Anwendung bereits mit .NET entwickelt wird, stellt die Verwendung Blazor sicher, dass jeder .NET-Entwickler im Team das Verhalten des Front-Ends der Anwendung verstehen und möglicherweise erstellen kann.

Entscheidungstabelle

In der folgenden Entscheidungstabelle sind einige der grundlegenden Faktoren zusammengefasst, die bei der Auswahl zwischen einer herkömmlichen Webanwendung, einer SPA oder einer Blazor App berücksichtigt werden müssen.

Weitere Überlegungen

Herkömmliche Web-Apps sind in der Regel einfacher und haben bessere Seo-Kriterien (Search Engine Optimization) als SPA-Apps. Suchmaschinen-Bots können Inhalte aus herkömmlichen Apps problemlos nutzen, während die Unterstützung für die Indizierung von SPAs möglicherweise fehlt oder eingeschränkt ist. Wenn Ihre App von der öffentlichen Ermittlung durch Suchmaschinen profitiert, ist dies häufig ein wichtiger Aspekt.

Wenn Sie kein Verwaltungstool für die Inhalte Ihres SPA erstellt haben, müssen Entwickler möglicherweise Änderungen vornehmen. Herkömmliche Web-Apps sind häufig einfacher für Nichtentwickler, Änderungen vorzunehmen, da ein Großteil des Inhalts einfach HTML ist und möglicherweise keinen Buildprozess benötigt, um eine Vorschau anzuzeigen oder sogar bereitzustellen. Wenn Nichtentwickler in Ihrer Organisation wahrscheinlich den Inhalt der App beibehalten müssen, ist eine herkömmliche Web-App möglicherweise eine bessere Wahl.

SPAs kommen zur Geltung, wenn die App komplexe interaktive Formulare oder andere Benutzerinteraktionen enthält. Für komplexe Apps, die eine Authentifizierung erfordern und daher nicht von öffentlichen Suchmaschinen-Spinnblättern zugänglich sind, sind SPAs in vielen Fällen eine hervorragende Option.