Blazor erlaubt es, ASP.NET direkt in einem Webbrowser laufen zu lassen. Das klingt jetzt erst einmal ziemlich abenteuerlich und es drängen sich Fragen auf wie: „Wie ist das möglich?“, „Ist das dann nicht unheimlich langsam?“ oder „Wer braucht das eigentlich?“
Diese Fragen sind natürlich alle berechtigt und ich werde hier der Reihe nach darauf eingehen. Aber vorerst möchte ich noch etwas abschweifen und ein paar Fakten aus der noch jungen Geschichte von Blazor erzählen.
Wie alles begann ...
Alles begann im Jahr 2017 als Steve Sanderson von Microsoft auf der NDC Conference in Oslo ein experimentelles Projekt vorgestellt hat, an dem er in seiner Freizeit gearbeitet hatte. Sein Vortrag ist auf YouTube verfügbar: https://www.youtube.com/watch?v=MiLAE6HMr10
Seine Idee wurde von der Community begeistert aufgenommen und so blieb ihm und somit auch Microsoft nichts anderes übrig, als dieses Projekt weiter zu verfolgen. Innerhalb der letzten zwei Jahre hat sich Blazor enorm weiterentwickelt und auch offiziell den experimentellen Status verlassen.
Blazor ist mittlerweile offizieller Bestandteil der ASP.NET Core 3.0 Preview, wird aber in der clientseitigen Variante nicht in die finale Version kommen. Aber aus Blazor ist auch ein Produkt entstanden, welches sehr wohl in den finale Release von ASP.NET Core 3.0 Einzug halten wird und das ist „Serverside Blazor“. Was es damit auf sich hat, kann in diesem Blog Beitrag von mir nachgelesen werden.
Wie geht das?
Aber nun erst einmal zurück zu der Frage, wie es möglich ist, DotNet in einem Webbrowser auszuführen. Die Antwort ist so einfach wie naheliegend: WebAssembly macht es möglich, .NET Code im Browser auszuführen.
Moment! Das würde ja bedeuten, dass .NET-Code erst in WebAssembly übersetzt werden müsste, um im Browser laufen zu können, wodurch ja im Endeffekt gar kein .NET-Code mehr im Browser läuft sondern WebAssembly??
Falsch! Es läuft tatsächlich .NET Code im Browser. Dabei wird der compilierte Bytecode in Form von DLL-Dateien – also genau dieselben DLLs, die wir sonst auch haben - in den Browser geladen und dort ausgeführt. Um das zu ermöglichen wird die Mono Runtime genutzt und damit sie auch im Browser läuft, wurde sie in ein WebAssembly Modul übersetzt. Somit läuft der .NET Code dann doch direkt im Browser, bekommt davon jedoch nichts mit, weil er, wie gewohnt, in eine .NET Runtime eingebettet ist.
Damit das Ganze so läuft wie es das tut, ist noch einiges mehr nötig als nur die Runtime in WebAssembly zu übersetzen, denn WebAssembly Module sind einigen Einschränkungen unterworfen. Wer hier Genaueres wissen möchte, kann das in diesem Blog Beitrag nachlesen.
Performance
Kommen wir nun zur nächsten Frage: Ist das nicht unheimlich langsam?
Wenn man sich die Schichten von ASP.NET Blazor einmal auf der Zunge zergehen lässt, so erkennt man, dass hier Bytecode von einer Runtime abgearbeitet wird, welche selbst wieder Bytecode ist, der von einer Runtime abgearbeitet wird. Der erste Gedanke dazu: Das kann eigentlich nur langsam sein!
Wieder Falsch! WebAssembly ist zwar vielleicht nicht der wundersame Turbolader für den Webbrowser, als der es immer wieder einmal angepriesen wird, aber es ist dennoch performant und im Durchschnitt grob ein Drittel schneller als vergleichbarer JavaScirpt Code. Daher ist es möglich, ASP.NET und C# in einer Geschwindigkeit im Browser laufen zu lassen, die eine flüssige Bedienung erlaubt, wie man sie auch von anderen clientseitigen Frameworks wie Angular oder React gewöhnt ist.
Und wozu das Ganze?
Die letzte Frage, nämlich die, wer eigentlich auf ASP.NET und C# im Browser gewartet hat, ist auch schnell beantwortet: Jeder der eine Single-Page-Application erstellen möchte und dazu weder JavaScript, TypeScript noch sonstige herkömmliche Technologien verwenden möchte, weil sein Team eben zum Beispiel mehr im DotNet-Bereich angesiedelt ist und hier viel Know How vorhanden ist.
Vor allem in Projekten, die sowohl den clientseitigen als auch den serverseitigen Teil einer Applikation abdecken, spielt eine Technologie wie Blazor ihre Vorteile sehr elegant aus. Es gibt für diesen Anwendungsfall sogar ein eigenes Template in Visual Studio, welches jeweils ein Project für den Client, eines für den Server (die API) sowie eines für die Models (DTOs) enthält. Im Gegensatz zu anderen clientseitigen Frameworks wie z.B. Angular kann man seine Models als gewöhnliche .NET Klassen zwischen Client und Server hin und her schicken, ganz ohne Codeverdoppelung, da die Daten das .NET Ökosystem nie verlassen müssen. Alleine dieser Punkt kann in großen Projekten bereits eine enorme Arbeitserleichterung darstellen.
Und wie sieht das nun aus?
Ein Vorteil von Blazor für einen DotNet Entwickler ist, dass er sich sogleich wie zu Hause fühlt. Eine Blazor Component sieht praktisch aus wie eine Page (cshtml) aus ASP.NET MVC. Für bedingtes Rendering und Schleifen verwendet man die bekannte Razor Syntax und für Events nutzt man eine ähnliche Technik, wie sie auch in Angular Verwendung findet, denn diese werden in Form von Attributen in den HTML-Code eingebunden.
Hier ein kleines Beispiel zur Verdeutlichung:
<ul>
@foreach (var name in Names)
{
<li>@name</li>
}
</ul>
<button @onclick="SaveData">Save</button
JavaScript?
In der Beschreibung von Blazor wird erwähnt, dass man völlig ohne JavaScript auskommt. Das ist meiner Meinung nach etwas missverständlich formuliert. Gemeint ist hier, dass es nicht nötig ist, während der Entwicklung selbst JavaScript Code zu schreiben. Man kann aber, wenn man das möchte, indem man JavaScript Interop nutzt.
Blazor selbst kommt natürlich nicht ohne JavaScript aus, das liegt vor allem auch an den Einschränkungen von WebAssembly. So benötigt man JavaScript, um ein WASM-Modul zu laden, JavaScript um eine Funktion eines WASM Moduls aufzurufen und Daten zu übergeben und man benötigt JavaScript zur DOM-Manipulation da WebAssembly gegenwärtig nicht in der Lage ist, auf das DOM des Browsers zuzugreifen.
Fazit
ASP.NET Blazor ist eine spannende, relativ neue Technologie, welche es einem DotNet Entwickler ermöglicht, schnell in die Entwicklung von Single-Page-Applikations einzusteigen. Ich persönlich finde die Idee, DotNet-Code im Browser auszuführen genial und wenn man sich ansieht, welche Fortschritte es bei Blazor seit der Vorstellung im Jahr 2017 gegeben hat, kann man nur voller Vorfreude in die Zukunft blicken. Auch wenn Blazor aktuell noch nicht für den produktiven Einsatz geeignet ist, so ist es nur eine Frage der Zeit bis das der Fall sein wird und spätestens dann wird es eine ernstzunehmende Alternative zu bestehenden clientseitigen Frameworks sein.
Weiterführende Links
Verfasst von Thomas Polaschek
