About a decade ago the mainstream Web stopped at a crossroad: JavaScript or native code? Silverlight was all the rage for a few years but then HTML5 won and Angular/React/Vue—all purely JS frameworks—have become mainstream. Today, Blazor comes up as a possible alternative to Angular/React/Vue and thanks to WebAssembly it opens up the web to be able to take advantage of existing development ecosystems, including .NET. Blazor is, to some extent, a modern attempt to revamp and refine the Silverlight concept—bringing the power of C# to client-side web development. In this session, I’ll discuss the underlying system architecture of an ASP.NET Blazor application and present a few examples.

1. ASP.NET Blazor
Dino Esposito
Digital Strategist, BaxEnergy

2. What’s that?
 Plain .NET Standard library with a Program.Main entry point that gets
downloaded and run in the browser
 Only the .NET runtime is compiled to WASM; the source code you
write in C# runs natively as if it were a normal .NET application
 Blazor code still runs in the same secure sandbox as JavaScript

4. Startup
 Once the Mono runtime has been downloaded, it begins the download
of the actual .NET assemblies
 The initialization step may take a while—about 3 seconds
 For this reason, the standard Blazor Visual Studio template provides a
dedicated area for the UI to show during the loading phase

5. Anatomy of a Blazor App

6. Components
 Blazor applications are a handful of pages
 Razor language and strong componentization
 A Blazor component is a self-contained chunk of HTML and C#.
 Any necessary CSS goes in separate files, reasonably named after the
component itself
 Blazor doesn’t do anything special with CSS and doesn’t impose any
convention
 Dealing with CSS is entirely up to you.

7. Digital Clock

8. Publishing
 Publishing a Blazor application is just as easy as publishing any other
ASP.NET application
 Doing this from Visual Studio will compile the application code and generate a
complete Web application with all of the final HTML, CSS, scripts and Blazor
binaries needed
 A good starting place is to use the Publish to Folder option
 All of the files of the application get put there.
 Dist folder contains a standard index.htm page and an _framework folder
 The _framework folder contains all of the compiled assemblies, as well as the
Blazor and Mono runtime components

9. More about Blazor components

10. Blazor and the others …
 Can be a simple frontend connected to any sort of HTTP backend
 Much like Angular and React and Vue
 Except it’s C# and WebAssembly
 Can be connected to a ASP.NET Core backend
 Can be a server-side application that outputs C# based client code
 Via SignalR and Azure SignalR

11. Server-side Blazor

12. ASP.NET Core Application
SignalR
WebSocket

13. Server-side hosting model
 Blazor runs on the server
 UI updates, event handling, invocation of JavaScript function is controlled
from within the server environment over a SignalR connection

14. How it works
 blazor.server.js
 Establishes the client connection
 blazor.boot.json
 List of resources
 SignalR negotiation
 Connection ID
 WebSocket opened
 Communication

15. {
"main":"StdServer.App.dll",
"entryPoint":"StdServer.App.Program::Main",
"assemblyReferences":
[
"Microsoft.AspNetCore.Blazor.dll","Microsoft.JSInterop.dll","netstandard.dll","
System.Xml.Linq.dll","System.Core.dll","System.dll","System.Xml.dll","mscorlib.
dll","Mono.Security.dll","System.Web.Services.dll","System.Transactions.dll","S
ystem.Runtime.Serialization.dll","System.ServiceModel.Internals.dll","System.Nu
merics.dll","System.Net.Http.dll","System.ComponentModel.Composition.dll","Syst
em.IO.Compression.FileSystem.dll","System.IO.Compression.dll","System.Drawing.d
ll","System.Data.dll","Microsoft.Extensions.DependencyInjection.Abstractions.dl
l","Microsoft.AspNetCore.Blazor.Browser.dll","Mono.WebAssembly.Interop.dll","Mi
crosoft.Extensions.DependencyInjection.dll","StdServer.App.pdb"
],
"cssReferences":[],
"jsReferences":[],
"linkerEnabled":false
}

16. Pros and Cons
 No page refreshes as if it were a pure client-side app
 Debugging as if it were regular ASP.NET
 No use of WebAssembly within the browser
 Pure server-side code
 Faster startup
 Every operation in the browser (not using JS) is over the network
 Doesn’t work offline
 Scalability is up to you. Welcome ASP.NET SignalR Azure.

17. Thoughts?