Angular oder Blazor? Eine Entscheidungshilfe für Webentwickler
Mit Blazor ist Microsoft als letzter der großen Player auf den SPA-Markt vorgedrungen. Blazor konkurriert gegen Platzhirsche wie Googles Angular. Für welche Zielgruppen eignen sich die Frameworks jeweils?
- Christian Liebel
Mit Blazor ist Microsoft als letzter der großen Player auf den Markt der Single-Page-App-Frameworks vorgedrungen. Dort konkurriert Blazor gegen alteingesessene Platzhirsche wie Googles Angular. Für welche Zielgruppen Angular und Blazor jeweils interessant sind, soll dieser Artikel klären.
Im März 2018 stellte Microsoft Blazor vor, ein von Steve Sanderson initiiertes Experiment, um .NET (zurück) in den Browser zu bringen: Statt auf JavaScript können Entwickler auf C# und die Templatesprache Razor zurückgreifen, um Webanwendungen zu entwickeln. Damit knüpft Blazor an das serverseitig ausgeführte ASP.NET MVC an.
Blazor ist nicht gleich Blazor
Zunächst müssen wir differenzieren zwischen den beiden Geschmacksrichtungen von Blazor: Da gibt es zunächst das serverseitig ausgeführte Blazor Server. Der Zustand der Anwendung wird hierbei vom Server verwaltet, Interaktionen der Nutzer führen zu einer Kommunikation mit dem Server über SignalR, auch HTML-Fragmente werden darüber ausgetauscht. Wenn besonders viele Nutzer die Anwendung gleichzeitig verwenden, wird der Server damit zum Bottleneck. Eine langsame Verbindung führt zu einem schlechten Antwortverhalten der Benutzeroberfläche.
Demgegenüber steht Blazor WebAssembly. Hier wird die Anwendung einschließlich der .NET-Runtime komplett clientseitig im Browser ausgeführt. Hier braucht es im einfachsten Fall lediglich einen statischen Webserver; der Browser muss die Technologie WebAssembly unterstützen. Einmal geladen kann die Anwendung auch offline ausgeführt werden. Wenn in diesem Artikel von Blazor die Rede ist, ist immer von der WebAssembly-Variante gemeint, die auch die von vornherein geplante Zielausbaustufe war. Blazor Server ist eher als eine Zwischenlösung anzusehen.
WebAssembly bringt viele Sprachen ins Web
WebAssembly (Wasm) ist ein Bytecode für das Web, der JavaScript ergänzen soll. Der große Vorteil von Wasm gegenüber dem menschenlesbaren JavaScript besteht darin, dass der Code weder geparst noch interpretiert werden muss. In anderen Sprachen geschriebener Programmcode (z.B. Rust, C#, Java) kann nach Wasm kompiliert und dann im Webbrowser ausgeführt werden.
Die Technologie soll JavaScript dabei nicht ersetzen, sondern für spezielle Anwendungsfälle ergänzen. WebAssembly-Code wird von derselben Engine ausgeführt, die auch JavaScript antreibt. Daher ist die Laufzeitperformance von Wasm-Code nicht zwingend besser als die von JavaScript-Anwendungen (siehe auch: Is WebAssembly magic performance pixie dust?). WebAssembly-Code unterliegt zudem derselben Sandbox wie JavaScript. Somit können nicht beliebige native Schnittstellen aufgerufen werden, sondern nur diejenigen, für die es auch passende APIs im Web gibt.
Um Blazor-Apps im Webbrowser auszuführen, wird zunächst die .NET-Runtime in Wasm heruntergeladen und gestartet. Als nächstes wird die passende Dynamic Link Library (DLL) mit der .NET-Assembly bezogen und auf der Runtime ausgeführt (Just in Time, ab .NET 6 soll Ahead-of-Time-Kompilierung möglich werden).
WebAssembly ist standardisiert und wird von den vier großen Evergreen-Browsern Firefox, Edge, Safari und Chrome plattformübergreifend seit geraumer Zeit von Haus aus unterstützt. Damit grenzt sich Blazor auch von Silverlight ab, dem schon lange abgekündigten, proprietären und Browser-Plug-in-basierten Ansatz, .NET-Anwendungen im Browser auszuführen.
Angular: Der Platzhirsch unter den SPA-Frameworks
Angular wurde im Jahr 2016 von Google veröffentlicht. Es basiert auf den Erfahrungen von Google mit dem Vorgängerframework AngularJS, das 2009 erstmals herausgegeben wurde. Dieses wiederum entstand auf Basis der Erfahrungen bei der Implementierung großer Webanwendungen wie Google Mail. Angular ist das meistverwendetste Framework bei Google selbst.
Die ab 2016 herausgegebene Variante basiert auf der Sprache TypeScript. Vergleichbar zu Razor erweitert Angular den HTML-Sprachumfang um eine Templatingsyntax. Vor der Ausführung im Browser müssen die TypeScript-Quelldateien nach JavaScript übersetzt werden. JavaScript wiederum kann direkt im Browser ausgeführt werden, weswegen Angular-Apps deutlich „webnäher“ sind als Blazor-Anwendungen.
Während bei Angular mittlerweile jede Version eine Long-Term-Support-Version (LTS) mindestens 18 Monate Unterstützung erhält, gibt es bei Blazor noch keine solche Version. Ferner sind Community und Ökosystem bei Angular bis jetzt größer als bei Blazor.
Argumente für Blazor
Blazor ist vor allem für die Teams interessant, die über Wissen im .NET- und C#-Bereich verfügen, im Umgang mit JavaScript aber eher weniger erfahren sind und die kein Wissen in diesem Bereich aufbauen können oder wollen: Ein großer Vorteil in der Verwendung von Blazor besteht darin, dass bestehender Quelltext eventuell ins Web mitgenommen werden kann. Frühere Investitionen in eine Codebasis bleiben somit erhalten.
Wie oben angemerkt ist das aber nur dann möglich, wenn die verwendeten Funktionen und Schnittstellen im Webbrowser zur Verfügung stehen, also in JavaScript implementiert werden könnten: Ein wahlfreier Zugriff auf das Dateisystem oder Geräteschnittstellen ist auch mit WebAssembly nicht möglich. Weiterhin kann C#-Code zwischen Server und Client geteilt werden, etwa Validierungslogik. Die bekannten Komponentenhersteller bieten auch für Blazor passende Komponenten an, eventuell sind diese in bestehenden Abonnements sogar schon enthalten und können einfach mitverwendet werden.
Argumente für Angular
Angular ist deutlich älter und damit auch reifer als Blazor. Viele Features, die Angular schon seit geraumer Zeit mitbringt und dort robust funktionieren, muss Blazor erst nachliefern: Das Lazy Loading von Anwendungsbestandteilen kam bei Blazor etwa erst mit .NET 5 hinzu. Andere Features sind noch gar nicht verfügbar. Vorne liegt Angular etwa bei Ahead-of-Time-Kompilierung, was für deutlich kleinere Bundlegrößen sorgt oder bei Live beziehungsweise Hot Reloading. Hier wird die Anwendung nach einer Änderung im Quelltext automatisch neu geladen, was die Entwicklerproduktivität deutlich steigert. Beides soll in Blazor erst mit .NET 6 im November diesen Jahres nachgereicht werden. Da Angular-Anwendungen vor Ausführung im Browser nach JavaScript übersetzt werden, kommen diese Apps ohne schwergewichtige Runtime aus: Eine einfache Hallo-Welt-Anwendung ist in Angular gerade einmal 170 Kilobyte groß, bei Blazor starten Anwendungen mit 2 Megabyte Dateigröße. JavaScript-basierte Browserschnittstellen können in Angular direkt aufgerufen werden, bei Blazor braucht es hingegen ein passendes NuGet-Paket oder die Verwendung der Interop-Brücke.
Fazit
Blazor bietet sich für die Entwickler an, die über Kenntnisse oder Bestandscode im .NET-Umfeld verfügen, bei denen ein Wechsel auf einen anderen Technologiestack nicht in Frage kommt und die höhere Bundlegrößen tolerieren können. Wichtig ist dabei, dass Blazor keine magische .NET-zu-Web-Übersetzungsmaschine ist: Auch Blazor-Entwicklern bleibt die Beschäftigung mit HTML, CSS, REST-APIs, CORS oder Betriebsmodellen in der Cloud nicht erspart, Berührungspunkte mit Webtechniken wird es also definitiv geben.
Selbst für .NET-Entwickler kann das auf TypeScript aufsetzende Angular interessant sein: Mit Anders Hejlsberg zeichnet sich derselbe Sprachdesigner für TypeScript verantwortlich wie auch für C#. Beide Sprachen beeinflussen sich oft gegenseitig und sind syntaktisch sehr ähnlich. Das Framework hat sich seit Jahren im Einsatz bewährt und aufgrund des weiterverbreiteten Einsatzes bei Google selbst dürfte die Weiterentwicklung noch auf Jahre gesichert sein. Entwickler ohne .NET-Hintergrund sind bei Angular vermutlich besser aufgehoben.
Schließlich ist festzustellen, dass sich beide Ansätze funktional nicht unterscheiden: Derselbe Funktionsumfang lässt sich mit Angular wie auch in Blazor umsetzen und plattformübergreifend zur Ausführung bringen.
