Blazor WebAssembly runs C# Razor components in the browser. Unlike Blazor Server, it does not execute component code on the ASP.NET Core server or require a persistent connection to keep the application running. That removes the connection dependency, not the need for HTTP when the application fetches server data. section 1.1.3 section 37.0 section 37.5
Components still use familiar Blazor features: Razor directives, event handlers, C# code, routing, and layouts. They need a separate project so they can be compiled for browser execution. An ASP.NET Core server can deliver the compiled application and expose web services; a shared data-model project can hold types used by both sides. section 37.2 section 37.3 section 37.3.2
Listing 37.5 Creating the Blazor WebAssembly project
dotnet new blazorwasm -o ../BlazorWebAssembly -f net7.0 dotnet add ../BlazorWebAssembly reference ../DataModel
The .NET 7 commands create the Blazor WebAssembly project and reference a shared DataModel project. section 37.2.2
A routed people list
A Pages/List.razor component declares @page "/forms" and @page "/forms/list". Its Create link uses href="forms/create": with a /webassembly/ base URL, that relative link reaches /webassembly/forms/create. A leading slash would instead leave that application root. The component can receive HttpClient through [Inject], then load people with GetFromJsonAsync<Person[]>("/api/people"). Deleting a person uses DeleteAsync on the person's API URL and refreshes the list after a successful response. section 37.3.2
The browser boundary matters. WebAssembly needs a supporting browser, and delivering the application requires a larger download. Browser-provided APIs also limit available .NET features: a component cannot use Entity Framework Core for SQL data access and must call a web service instead. Blazor WebAssembly is therefore a useful C# client-side option, not a drop-in replacement for every server-side feature. section 37.0 section 37.3.2
