Blazor WebAssembly vs. Blazor Server – Welche Unterschiede gibt es und wann wähle ich was?

Das Blazor Framework von Microsoft gibt es inzwischen in drei "Geschmacksrichtungen". Die erste ist Blazor WebAssembly, die zweite Blazor Server, und zu guter Letzt gibt es noch Blazor Hybrid. In diesem Artikel wollen wir uns die zwei "echten", also Browser-basierten, Web-Anwendungs-Szenarien WebAssembly und Server anschauen.

In diesem Artikel:

Blazor WebAssembly vs. Blazor Server – Welche Unterschiede gibt es und wann wähle ich was?
Sebastian Gingter ist Consultant und „Erklärbär“ bei Thinktecture. Seine Spezialgebiete sind Backend-Systeme mit .NET Core und IdentityServer.
Der Fokus dieses Artikels liegt insbesondere darauf, welcher dieser beiden unterschiedlichen Technologieansätze für welche Anwendungsfälle passender ist. Blazor Hybrid fällt aus dieser Betrachtung heraus, denn die Hybrid-Variante zielt nicht auf Webanwendungen ab, sondern auf reine Desktop-Anwendungen. Sie ermöglicht es, Blazor-Komponenten mittels einer WebView-Komponente in Windows Forms-, WPF- sowie MAUI-Anwendungen zu integrieren. Blazor Hybrid ist also kein Werkzeug für „echte“, Browser-basierte Webanwendungen, und damit nicht Inhalt unserer Betrachtung.

Blazor

Blazor erlaubt es Entwicklern, die Logik von Web-Applikationen in C# zu schreiben. Das HTML der Web-Anwendung wird dabei, ähnlich zu ASP.NET (Core) MVC, mittels der auch auf C# basierenden Razor Template Engine generiert. Wer also schon vorher mit ASP.NET (Core) serverseitig gerenderte Webanwendungen gebaut hat, wird sich hier sehr schnell zurechtfinden. Dabei gibt es zwei Varianten, mit denen man Blazor-Anwendungen in den Browser bekommen kann, die aber unterschiedlicher nicht sein könnten. Um die Unterschiede zwischen diesen beiden Ansätzen etwas deutlicher aufzuzeigen, wollen wir zunächst ein wenig in die Vergangenheit schauen.

Kostenloses Whitepaper: ASP.NET Core Blazor WebAssembly

Christian Weyer hat zum Thema „ASP.NET Core Blazor WebAssembly – das SPA-Framework für .NET-Entwickler?“ ein Whitepaper erstellt, in dem er alles Wissenswerte zusammengefasst hat.

Melden Sie sich kostenlos zu unserem Newsletter an, um das Whitepaper per E-Mail zu erhalten.

Klassische Web-Anwendungen bis hin zu Single-Page Applications

Die ersten Web-Anwendungen, wie sie bereits in der Mitte 90er Jahren aufkamen, waren ausschließlich Server-rendered. Mittels eines Interpreters wie beispielsweise Perl oder PHP wurden die Anfragen des Webbrowsers ausgewertet, und eine neue Antwort-Seite erzeugt, die dann zum Browser geschickt wurde. Für den Browser, und damit den Nutzer, war also jede Operation in der Web-Anwendung mit einem vollständigen neuen Laden der Seite verbunden.

request_response
Server rendered WebApplications (vereinfacht)
Da das Web als Plattform und das verwendete Protokoll HTTP an sich zustandslos sind, der Sinn und Zweck von Anwendungen aber grundsätzlich immer irgendwie die Darstellung und auch die Veränderung von Zuständen ist, ergab sich hier sehr schnell ein gewisses Problem: Wie (und wo) verwalte ich den Zustand?
Eine damals übliche Variante war das Halten des Zustandes auf dem Server, und zwar meistens im Arbeitsspeicher im Rahmen einer Sitzung. Um den Zustand einer neuen Anfrage des gleichen Browsers wieder zuzuordnen, wird eine ID der Sitzung mittels eines Cookies übertragen. Skalierung war damals meist keine Anforderung, sodass man sich in der Regel mit der Problematik mehrerer Webserver und auf welchem von diesen der Zustand liegt in aller Regel nicht ernsthaft beschäftigen musste.
Als .NET erstmals im Jahre 2002 veröffentlicht wurde, lernten wir eine neue Variante des Zustandsmanagements kennen: ASP.NET WebForms basierte damals, analog zu den bisherigen Desktop-UI-Frameworks, auf Komponenten. Jede Komponente, also jedes Element auf der Webseite, hielt ihren eigenen Zustand. Um diesen zwischen Anfragen beizubehalten, wurde dieser Zustand kurzerhand serialisiert und in unsichtbaren Formular-Elementen übertragen. Dieser sogenannte ViewState führte allerdings sehr schnell zu extrem großen Datenpaketen, die bei jeder Anfrage zwischen Browser und Server übertragen werden mussten, sodass der Server bei jeder Anfrage den letzten Zustand der Seite wieder deserialisieren und auswerten konnte.
Mit der Zeit wurde JavaScript immer mächtiger (und schneller) und so wurde es möglich, immer mehr der Oberflächen-Logik im Browser auszuführen. Damit verschob sich aber auch der Ort, an dem der Zustand benötigt und verarbeitet wurde, vom Server hin zum Client.
Single Page Applications (vereinfacht)
Moderne Single-Page Applications (SPAs), wie sie z.B. mit den Frameworks Angular, React oder Vue erstellt werden, halten nun den Zustand vollkommen innerhalb der JavaScript-Runtime im Browser und sind damit sogar in der Lage, vollständig offline zu arbeiten – sofern bei der Planung und Implementierung der Anwendung darauf geachtet wird, auch wirklich alle dafür notwendigen Daten im Browser vorzuhalten. Sobald sie wieder eine Internetverbindung zum Server haben, können sie ihren Zustand mittels Anfragen an den Server synchronisieren. Aufseiten des Servers muss dazu eine Web-API bereitgestellt werden, mit der die Single-Page Application kommunizieren kann.
Egal, welches Framework man für die Entwicklung einer Single-Page Application einsetzt, es wird immer eine Gemeinsamkeit geben: Der Code, der am Ende im Browser des Clients läuft, besteht grundsätzlich aus JavaScript. Also, auch wenn man seine APIs für das Backend mit C# schreibt, muss für das Frontend JavaScript oder z.B. TypeScript verwendet werden. Es gibt hier also einen signifikanten Technologiebruch zwischen Client und Server.
Blazor ist eine Technologiefamilie von Microsoft, die diesen Technologiebruch entschärft, weil hier die überwiegenden Teile des Frontends ebenfalls in C# programmiert werden können. C#-Entwickler können daher – abhängig von Struktur und Architektur ihres existierenden Projektcodes – Teile von bereits vorhandenem C#-Code in ein Blazor-Projekt übernehmen. Gleichzeitig ist die Lernkurve bei Blazor für C#-Entwickler nicht so steil wie bei den JavaScript-basierenden Frameworks. Der Entwickler ist in der Lage, viel bereits bekanntes Wissen über .NET, C# und Razor auch in Blazor anzuwenden.
Für viele Teams mit umfangreichen C#-Anwendungen eröffnet sich hier also ein interessanter Weg in die Webwelt, der weniger radikal als die verbreiteten JavaScript-basierten Ansätze daherkommt. Schauen wir uns in den nächsten beiden Kapiteln daher einmal genauer an, warum es Blazor in zwei Geschmacksrichtungen als Blazor WebAssembly und als Blazor Server gibt.

Blazor WebAssembly

Blazor WebAssembly adaptiert sehr stark die Architekturüberlegungen und Denkmuster der etablierten Single-Page Application Frameworks. Der Unterschied von Blazor WebAssembly zu einer JavaScript-basierten SPA besteht hauptsächlich darin, dass tatsächlich unser .NET Code im Browser ausgeführt wird. Dies geschieht unter Verwendung des WebAssembly-Standards in einem mehrstufigen Prozess.

Wie wir auf dem Screenshot sehen, lädt die Anwendung erst JavaScript vom Webserver nach. Dies sind unter anderem die Dateien blazor-webassembly.js und, in diesem Fall, die dotnet.6.0.3.lfvem528fq.js. Diese Dateien enthalten den Code, um eine nach WebAssembly kompilierte vollständige .NET Laufzeitumgebung zu laden und innerhalb der WebAssembly-Laufzeitumgebung des Browsers zu starten. Diese .NET Laufzeitumgebung (die nun als ein sogenanntes WebAssembly-Modul im Browser läuft), lädt nach dem Start die benötigten .NET Framework-Assemblies, das Einstiegs-Assembly unserer Blazor Web-Anwendung, sowie alle anderen weiteren referenzierten Assemblies nach. Hierbei sollte man sich bewusst sein, dass unsere Anwendung derzeit unmittelbar als IL-Assembly auf dem Webserver liegt, der die Anwendung ausliefert. Es kann also jeder mit Netzwerkzugriff auf diese Maschine das Assembly unserer Anwendung herunterladen und dekompilieren. Wie man auf dem Bild oben sehen kann, werden für die Demo-Anwendung aus der unveränderten Blazor WebAssembly Projektvorlage aktuell ca. 10,5 MB über das Netzwerk übertragen. Aber keine Panik: die Assemblies werden allesamt gecached, das bedeutet nur der allererste Start unserer Anwendung ist so groß, beim zweiten Mal fließen nur noch ca. 720 KB über das Netzwerk.

Hinweis: Der Browser unseres Benutzers muss dazu echte .NET IL Assemblies, also klassische binäre .dll-Dateien, von unserem Webserver herunterladen. Das ist allerdings etwas, das viele Firewalls, insbesondere die etwas restriktiveren im Unternehmensumfeld, nur zu gerne aktiv unterbinden: Der Download von ausführbaren Dateien kann daher blockiert sein – und damit ist unsere Blazor WebAssembly Anwendung nicht ausführbar.

War der Download erfolgreich, wird unsere .NET-Anwendung in der .NET Runtime in der WebAssembly Runtime gestartet. Diese erzeugt die erste Seite unserer Applikation, erzeugt eine Instanz jeder sichtbaren Komponente und hält darin den Zustand, nahezu so, wie in den Komponenten einer klassischen Desktop-Anwendung (WinForms oder WPF).
An dieser Stelle ergibt sich eine technische Herausforderung: Aus der WebAssembly Runtime heraus, kann (noch) nicht direkt auf das Document Object Model (DOM), also der programmatischen Repräsentation der HTML-Struktur, zugegriffen werden. Alle Eingaben des Benutzers, also z.B. jeder Mausklick oder auch Texte, die in einem Textfeld eines HTML-Formulars eingegeben werden, passieren allerdings im DOM. Auch alle Ausgaben unserer Anwendung, die in der WebAssembly-Runtime für eine einzelne Komponente berechnet und aus denen daraufhin HTML gerendert wird, müssen dorthin übertragen werden.
 
Blazor abstrahiert diese technische Hürde für uns. Dafür stellt es eine Brücke zwischen JavaScript und WebAssembly bereit, und über diese Brücke werden alle Eingaben, die auf der DOM-Seite passieren in unsere WebAssembly-Runtime, und damit in unsere Anwendung, herübergereicht. Genauso werden alle Aktualisierungen der Oberfläche, also jedes neu hinzugefügte, geänderte oder entfernte HTML-Elemente, aus unserer Anwendung von der WebAssembly-Runtime aus in das DOM übertragen. Daneben kann unser C#-Code über diese Brücke auch normale JavaScript-basierte APIs des Browsers aufrufen (z.B. um Daten im Session- oder Local Storage abzulegen oder daraus auszulesen). Genauso ist es auch aus der JavaScript-Seite heraus möglich, C# Code in der WebAssembly-Welt aufzurufen. In der folgenden Abbildung ist diese Brücke unten links als der mit Interop bezeichnete Teil zu finden.
Blazor WebAssembly (vereinfacht)

Mittels der PWA-Erweiterungen (Progressive Web Apps) für Blazor WebAssembly ist es, wie auch bei reinen JavaScript-basierten SPAs, möglich, die Anwendung durch das Bereitstellen eines sogenannten Manifestes und eines Service Workers im Browser zwischenzuspeichern und damit eine vollständig offline fähige Anwendung zu erstellen. Natürlich stehen uns in der JavaScript-Runtime des Browsers auch nur Browser-APIs zur Verfügung. Von hier aus können z.B. keine normalen Socket-Verbindungen aufgebaut werden, wie es z.B. für einen Datenbankzugriff notwendig ist.

Blazor Server

Blazor Server verfolgt einen deutlich anderen Ansatz als Blazor WebAssembly. Statt der Ausführung unseres Applikationscode im Browser, führt hier der Server unsere Anwendung aus. Das heißt konkret: Wenn ein Browser die Anwendung startet, werden alle Komponenten auf dem Server instanziiert und halten auch dort ihren Zustand. Der initiale Zustand, also das HTML der neu gestarteten Anwendung, wird wie bei Server-Rendered Seiten an den Browser übertragen.
Nun folgt ein technischer Kniff, und dabei spielt die gerade bei Blazor WebAssembly erwähnte JavaScript-Brücke eine große Rolle. Wir erinnern uns: Diese Brücke hat das DOM im Browser mit dem .NET Code in der WebAssembly-Runtime verbunden. Nur läuft der .NET Code jetzt nicht mehr im Browser, sondern auf unserem Server.
Ein kleines JavaScript, das zu Blazor Server gehört, baut eine SignalR-Verbindung vom Browser zu unserem Server auf. SignalR ist eine Technologie von Microsoft, die es sehr einfach macht, eine Zwei-Wege-Echtzeit-Kommunikation zwischen Browser und Server zu implementieren. SignalR setzt dabei auf eine normale WebSocket-Verbindung auf, kann aber im Fehlerfall auch auf Server-Sent Events und zur Not auf langlaufende Http-Requests zurückfallen, ohne das man als Entwickler auf solche Fälle selber reagieren müsste.
Die erwähnte JavaScript-Brücke wird nun durch diese SignalR-Verbindung hindurch sozusagen lang gezogen: von unserem DOM im Browser über das Netzwerk bis hin zu der laufenden Anwendungs-Instanz auf dem Server. Eingaben des Benutzers werden nun durch die JavaScript-Brücke zum Server geschickt und dort verarbeitet. Alle daraus resultierenden Änderungen am HTML der Komponenten werden durch diese Verbindung wieder zum Browser gesendet und dort angezeigt. Der gesamte Ladevorgang der Seite bis die Anwendung läuft benötigt nur ein paar hundert Kilobyte.
Blazor Server (vereinfacht)
Das verwendete Protokoll auf der SignalR-Verbindung ist binär und relativ klein, denn es werden nur Browser-Events zum Server bzw. HTML-Differenzen zurück zum Browser übertragen.

Wie man auf dem folgenden Screenshot sieht, wird auch hier wieder ein JavaScript geladen, aber dann wird die SignalR-Verbindung aufgebaut und die Anwendung läuft.

Und ja: Die Ähnlichkeit dieses Konzeptes mit Mainframes (Server) und Terminals bzw. Thin-Clients als Eingabe-Ausgabe-Schnittstelle (Browser) sind nicht von der Hand zu weisen.

Was bedeutet dieser Unterschied?

Dieser Hauptunterschied, dass unsere Anwendung statt im Browser jetzt (wieder) auf dem Server „lebt“, hat drei konkrete, sofort spürbare Auswirkungen:
  1. Es wird eine permanente Verbindung zwischen Server und Browser benötigt. Blazor Server Anwendungen sind grundsätzlich nicht offline-fähig.
  2. Wir unterliegen keinen API-Limits des Browser mehr: Zugriffe unseres Codes auf dem Server auf spezielle Schnittstellen und externe Hardware fallen deutlich leichter (z.B. Industriemaschinen, Scanner, Sensoren, Bus-Systeme, direkte Datenbankzugriffe etc.). Auch, weil nun sehr leicht externe Bibliotheken dafür eingebunden werden können.
  3. Auf dem Server kann unsere Anwendung mit anderen APIs über beliebige Protokolle kommunizieren. Eine aufwendige Anpassung an das Web oder Serialisierung/Deserialisierung über HTTP(S) können entfallen.

Da die Anwendung auf dem Server ausgeführt wird, und nur die reine HTML-Oberfläche ohne Logik im Browser, benötigen wir jedoch eine permanente, stabile Netzwerk-Verbindung zwischen unserem Browser und dem Webserver. Idealerweise haben wir hier auch eine möglichst niedrige Latenz, damit unsere Eingaben möglichst schnell zum Server kommen, bearbeitet werden und die Antwort wieder zurückkommt. Haben wir eine große Latenz, fühlt sich die Anwendung extrem langsam an und der Nutzer muss für jede einzelne Aktion an der Oberfläche lange warten bis die Anwendung reagiert. Der Benutzer sollte also im besten Fall möglichst nahe am Server verortet und möglichst latenzfrei (LAN statt WAN) angebunden sein.

Der Ansatz, die Anwendung auf dem Server laufen zu lassen, bedeutet auch, dass der Server für alle gleichzeitigen Nutzer die entsprechenden Ressourcen bereithalten muss. Das sind zum einen Netzwerkanbindung und -bandbreite, zum anderen aber vor allem ausreichend Arbeitsspeicher, um den Zustand aller gleichzeitigen Verbindungen zu halten und zum dritten ausreichend CPU-Kapazitäten, falls die Anwendung rechenintensive Aufgaben für jeden Nutzer ausführen muss. Im Gegenzug wird hier der Client entlastet und so kann unsere Webanwendung auch auf eher schwachen Rechnern wie z.B. Chromebooks oder Tablets wie z.B. den günstigen Amazon Fire-Geräten effizient genutzt werden.

Der zweite Punkt eröffnet uns dabei sehr interessante Möglichkeiten: Wir können beispielsweise direkt aus unserer Webanwendung heraus auf Datenbanken zugreifen, ohne erst eine Web-API zwischen dem Web-Frontend und dem Server-Backend entwerfen und implementieren zu müssen. Dies erspart viel Arbeit. Genauso können wir z.B. schon existierende Bibliotheken weiterverwenden, auch wenn wir diese nicht nach WebAssembly kompilieren können.

Nicht zu vergessen ist auch, dass unsere Assemblies nicht mehr ungeschützt auf einem Webserver herumliegen. Unser Code wird nur auf dem Server ausgeführt und lediglich das erzeugte HTML wird zum Browser übertragen. Man kann also ggf. sensitive Businesslogik unmittelbar in der Webanwendung verwenden, ohne Gefahr zu laufen, dass diese später dekompiliert in einem öffentlichen GitHub-Repository auftaucht.
 
Dabei sollten wir allerdings im Hinterkopf behalten, dass uns Blazor als Technologie grundsätzlich die Option offen hält, dass wir die gleichen Komponenten sowohl in Blazor WebAssembly als auch in Blazor Server verwenden können. Wenn wir dies tatsächlich machen wollen, dann müssen wir dennoch darauf achten, die Zugriffe auf Datenbanken oder rein serverseitige APIs in einer solchen Art zu kapseln, dass wir diese für Blazor WebAssembly auch über klassische Web-API Aufrufe ausführen können. Tun wir dies nicht, so verbauen wir uns die Möglichkeit, direkt von Blazor Server auf Blazor WebAssembly zu wechseln und haben später einen höheren Aufwand, diese Abstraktionen und APIs doch noch nachträglich einzubauen.

Wann nehme ich was?

Falls Blazor als Technologie für ein Projekt grundsätzlich infrage kommt, dann stellt sich die Frage, ob man Blazor WebAssembly oder Blazor Server wählen sollte.
Wähle deinen Weg

Blazor WebAssembly ist geeignet, wenn unsere Anwendung auch offline funktionieren soll. Auch wenn wir starke Clients haben, können wir die Last dorthin verschieben und von den Browser-APIs profitieren. Dies ermöglicht uns, die Anwendung als echte Progressive Web-App zu erstellen. Wir müssen jedoch bedenken, dass vor allem Firewalls von Firmen hier etwas übereifrig sein und unsere Anwendung blockieren könnten.

Blazor Server ist dann eine Option, wenn man sicherstellen kann, dass alle Clients eine stabile Netzwerkverbindung mit geringer Latenz zum Server haben. Wenn unsere Anwendung ressourcenintensiv ist, kann diese so auch für günstige Client-Geräte nutzbar gemacht werden, indem wir zentral auf dem Server die entsprechenden Ressourcen bereitstellen. Wenn unsere Anwendung vom Server aus unmittelbar mit speziellem Code, APIs oder Bibliotheken kommunizieren muss, und diese nicht als Web-APIs bereitstehen bzw. nur sehr aufwändig bereitzustellen sind, kann Blazor Server auch den Aufwand eine Oberfläche zu Web-ifizieren reduzieren. In solchen Fällen bietet Blazor Server die Möglichkeit, diesen Code mit weniger Aufwand in einer neuen, Web-basierten Anwendung wiederzuverwenden. Allerdings ist dies genau so bei ASP.NET MVC oder Razor-Pages Anwendungen der Fall.

Auch die dritte Option, beides zu kombinieren, möchte ich an dieser Stelle nicht verschweigen: Man kann z.B. eine Anwendung primär als Blazor WebAssembly bereitstellen, aber für die Benutzer, die z.B. durch eine Firewall am Download der Assemblies gehindert werden, die gleiche Anwendung als Fallback auch in der Server-Version betreiben.

Zuletzt rufen wir uns wieder ins Gedächtnis, dass Blazor in beiden Fällen einfach Blazor ist. Wir können also eine (UI-)Komponentenbibliothek und auch die Businesslogik so erstellen, dass sie unabhängig von den jeweils speziellen APIs ist. Diesen Code können wir dann in Anwendungen verwenden, die wir mit Blazor WebAssembly auf die Geräte schieben – und zeitgleich auch in anderen Blazor Server-Anwendungen wiederverwenden.

Blazor @ Thinktecture

Oftmals werden wir gefragt, welche Technologie aus unserer Sicht „die richtige“ sei. Das hängt selbstverständlich immer von allen Gesamtumständen ab und es gibt darauf keine universelle Antwort. Dennoch haben wir eine Meinung dazu:

Grundsätzlich – komplett unabhängig von Technologieen – stellt sich bei Web-basierten Anwendungen heutzutage immer auch noch die Frage, ob es eine SPA sein muss, oder ob eine klassische, vom Server gerenderte, Webanwendung nicht doch ausreicht. SPAs kommen dabei zwangsläufig immer mit einer etwas höheren Komplexität daher: Wir bauen eine Fat-Client Anwendung mit eigener Zustandshaltung und diesen müssen wir irgendwie mit dem Zustand auf dem Server synchron halten. Wir müssen die Browser-Navigation mit einbeziehen (Routing), wir sind auf Browser-APIs beschränkt. Diese höhere Komplexität bietet uns aber bei Progressive Web Apps (PWA) eben auch die Möglichkeit, eine vollständig offlinefähige und damit „richtige“ Mobile-App zu bauen – und dabei alles aus der Plattform Web herauszuholen was sie uns anbietet, ohne plattformspezifischen Code schreiben zu müssen. Generell sagen wir daher: Eine SPA ergibt genau dann Sinn, wenn wir sie auch wirklich benötigen. Brauchen wir die Optionen die uns eine SPA bietet nicht, spricht eher vieles für klassische Server-Rendered Anwendungen, denn es ist in der Tat viel einfacher.

Und was bedeutet das für Blazor?

Blazor Server ist, wie der Name schon sagt, eine Server-Technologie. Wenn unsere Webanwendung also sowieso schon auf dem Server leben muss und offline gar nicht funktionieren kann, dann stellen wir uns natürlich die Frage, warum man die Anwendung dann nicht gleich als eine normale Server-Rendered Anwendung, z.B. mit ASP.NET Core MVC oder Razor Pages erstellt? Welchen Mehrwert würde uns Blazor Server bieten, um den Mehraufwand und die höhere Komplexität einer SPA-Technologie zu rechtfertigen? Wir finden: Eigentlich keinen.

Blazor WebAssembly ist hingegen ein richtiges SPA-Framework das es uns ermöglicht echte Browser-basierte Anwendungen zu bauen die auch in der Lage sind, alle SPA-Vorteile voll auszuspielen.

Fazit

Blazor WebAssembly wird im Web-Browser ausgeführt, wohingegen eine Blazor Server-Anwendung auf dem Server „lebt“. Blazor Server ist mit seinem Ansatz eher mit einer Anwendung die via „Remote Desktop“ bzw. „X11 fürs Web“ bereitgestellt wird zu vergleichen. Der Ansatz von Blazor WebAssembly erlaubt es, eine richtige, potentiell auch rein offlinefähige, Single-Page Application zu erstellen. Blazor-Komponenten können, sofern sie der richtigen entkoppelten Architektur folgen, ohne Änderungen in beiden Anwendungsmodellen verwendet werden.

Bei der Entscheidung, welche dieser Technologien die richtige für ein Projekt ist, muss man unter anderem die Punkte der gegebenen Netzwerkumgebung, das Lastverhalten und die Verfügbarkeit bzw. die Abhängigkeiten von Browser- bzw. Serverspezifischen APIs berücksichtigen.

Blazor Server kann dabei ein Sprungbrett hin zur echten SPA sein oder ein Fallback falls es technische Schwierigkeiten mit dem Deployment-Modell von WebAssembly gibt. Falls man allerdings keine SPA benötigt, sind Server-Rendered Anwendungungen wie Razor Pages oder ASP.NET Core MVC genau so gute Alternativen zu Blazor Server.

Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Diese Artikel könnten Sie interessieren
.NET
Incremental Roslyn Source Generators in .NET 6: Adapt Code Generation Based on Project Dependencies – Part 5

Incremental Roslyn Source Generators in .NET 6: Adapt Code Generation Based on Project Dependencies – Part 5

The Roslyn Source Generator, implemented in the previous articles of the series, emits some C# code without looking at the dependencies of the current .NET (Core) project. In this article our DemoSourceGenerator should implement a JsonConverter, but only if the corresponding library (e.g. Newtonsoft.Json) is referenced by the project.
08.07.2022
Three different textured walls
.NET
Dependency Injection Scopes in Blazor

Dependency Injection Scopes in Blazor

The dependency injection system is a big part of how modern ASP.NET Core works internally: It provides a flexible solution for developers to structure their projects, decouple their dependencies, and control the lifetimes of the components within an application. In Blazor - a new part of ASP.NET Core - however, the DI system feels a bit odd, and things seem to work a bit differently than expected. This article will explain why this is not only a feeling but indeed the case in the first place and how to handle the differences in order to not run into problems later on.
31.05.2022
.NET
Asynchrone Operationen: Blazor WebAssembly für Angular-Entwickler – Teil 5 [Screencast]

Asynchrone Operationen: Blazor WebAssembly für Angular-Entwickler – Teil 5 [Screencast]

Eine Webanwendung will natürlich auch mit Daten gefüttert werden. Doch diese müssen irgendwo her kommen. Nichts liegt näher als diese von einer Web API zu laden. Dieser Screencast zeigt, wie asynchrone Operationen in Blazor funktionieren und welche gravierenden Unterschiede es zu Angular gibt.
26.05.2022
.NET
Typings: Blazor WebAssembly für Angular-Entwickler – Teil 4 [Screencast]

Typings: Blazor WebAssembly für Angular-Entwickler – Teil 4 [Screencast]

C# und TypeScript entstammen der Feder der selben Person. Doch sind sie deshalb auch gleich? In diesem Teil der Screencast-Serie erfahren Sie, wie mit Typen in den beiden Programmiersprachen verfahren wird und welche Unterschiede es gibt.
19.05.2022
.NET
Bindings: Blazor WebAssembly für Angular-Entwickler – Teil 3 [Screencast]

Bindings: Blazor WebAssembly für Angular-Entwickler – Teil 3 [Screencast]

Wer Komponenten einsetzt, steht früher oder später vor der Fragestellung, wie man Daten an die Komponente übergibt oder auf Ereignisse einer Komponente reagiert. In diesem Screencast wird gezeigt wie Bindings bei Komponenten funktionieren, also wie eine Komponente Daten von außerhalb benutzen und Rückmeldung bei Aktionen geben kann.
12.05.2022
.NET
Incremental Roslyn Source Generators in .NET 6: Increasing Performance through Harnessing of the Memoization – Part 4

Incremental Roslyn Source Generators in .NET 6: Increasing Performance through Harnessing of the Memoization – Part 4

In Part 1 of this series we've implemented a simple Incremental Source Generator. Although we looked at all mandatory phases of an IIncrementalGenerator, still, the consideration was quite superficial. One of the biggest advantages of the new API, which makes the Source Generator an incremental one, is the built-in memoization, i.e. caching. To take full advantage from it, we have to make some preparations so Roslyn knows what to cache and how to compare the results of each phase.
10.05.2022