Alle mod­er­nen Brows­er kön­nen heute WebAssem­bly-Byte­code als Alter­na­tive zu JavaScript aus­führen. Gedacht war WebAssem­bly für Berech­nun­gen im Hin­ter­grund, daher gibt es auch im Stan­dard keine direk­te Inter­ak­tion mit dem DOM. Einige mod­erne Frame­works haben diese und andere Beschränkun­gen (wie den fehlen­den Garbage Col­lec­tor) aber bere­its überwunden.

Dieser Vor­trag stellt WebAssem­bly am Beispiel Bla­zor von Microsoft vor, mit dem man auch kom­plexe Sin­gle Page Web Apps mit .NET und C# entwick­eln kann. JavaScript wird nur noch bei spezielleren Brows­er-API-Zugrif­f­en gebraucht. Was wun­der­bar klingt für alle Entwick­ler, die gerne eine typ­isierte Hochsprache und/oder beste­hen­den .NET-Code zur Web App-Pro­gram­mierung ver­wen­den wollen, hat aber auch einige Nachteile, die dieser Vor­trag aufzeigen wird.

Am Ende schaut der Vor­trag auch über Bla­zor WebAssem­bly hin­aus auf die anderen Spielarten von Bla­zor: Bla­zor Serv­er, Bla­zor Desk­top und Bla­zor MAUI, mit denen man auf ein­er Code­ba­sis nicht nur für den Brows­er, son­dern auch native Apps für Win­dows, Android, iOS und macOS schreiben kann. Zudem gibt es auch eine Demo, wie man WebAssem­bly via “WASI” auch direkt auf ver­schiede­nen Betrieb­ssys­te­men laufen lassen – ohne Brows­er, aber mit Sandbox.