The Differences Between Blazor WebAssembly And Blazor Server

If you are aware of the latest developments in .NET for the last couple of years, you must have heard the buzzword ‘Blazor’ quite often. It is a revolutionary client-end User Interface framework developed by Microsoft’s mighty ASP.NET Expert team. Since its launch, it has become a big talking point among the Tech Organizations and Developer community. Blazar offers an amazing ability to code enriched web User Interfaces/User Experiences by using CSS, C#, and HTML instead of using JavaScript, a proposition most of the Developers have been dreaming of for long.

What is Blazor?

Blazor is an open-source and freely available framework, which allows developers to develop highly interactive web applications by using C# programming language. It allows a single programming language C#, HTML or Razor to write both the Client-side and Server-side code. Blazor achieves this by using .NET runtime which is compiled into WebAssembly bytecode. The .NET runtime functions into the browser and can allow any .NET DLL to execute, including the code we have written in C# programming language.

Let us take a detailed view of Blazor’s two hosting models to enhance our understanding of their viability.

1. The Blazor Server
2. Blazor WebAssembly

1. The Blazor Server

This hosting model allows an application to be executed on the server. It establishes a SignalR connection between the Server and the Client. Whenever any event occurs at the client’s end, that information is passed over to the Server over the SignalR connection. Once the information is received by the Server, it handles the event and calculates the difference for the generated HTML.

Then for any further communication with the client, the Server only sends the difference of the HTML over the SignalR connection, and once the client receives it, it updates the User Interface (UI). The browser plays an important role to update the UI since only the difference is applied to update the UI, the application executes fast and offers a highly responsive experience to the end-user.

A Blazor application can easily run on an ASP.NET core backend and could be accessed easily by a browser. The ASP.NET Core applications can either be running on IIS or could be hosted as self-contained applications. Blazor application or website could be accessed by any browser at client-side. Blazor Server utilizes a JavaScript file to function and use CSS and HTML to render its user interface (UI). Here it is important to note that Blazor Server does not use WebAssembly. 

2. Blazor WebAssembly

Blazor WebAssembly is the second hosting model offered by Blazor, which is used to host different Blazor components. Blazor WebAssembly has a .NET runtime incorporated in WebAssembly, which offers a standardized bytecode for the web applications. This .NET runtime is easily downloaded along with the Blazor WebAssembly application and it enables executing normal .NET code directly in the browser itself. It offers a unique proposition where no extra plugin or additional code is required for transpiration.

Blazor WebAssembly is supported by all the renowned modern web browsers available in the market for both mobile and desktop. Its execution is quite like JavaScript, where it allows the WebAssembly applications to execute securely on the end-users device, that too within the browser’s security sandbox. It offers an ability to the applications so that they could be deployed as a true standalone static site, without any .NET server component. The applications can be amalgamated with ASP.NET Core, which ensures a full stack web development with the help of .NET ecosystem, that is where the application code can be effortlessly shared with the server and the client.

Blazor Server vs WebAssembly – Ways They Differ

Now back to square one, we still have the same question in our mind, which hosting model we should use to create a Blazor application?

Honestly speaking, it all depends on the objective purpose and the features to be offered by the proposed application, that we are planning to create. If you are looking for a standard application which is supposed to be used at a location with bad internet connectivity, then we will certainly opt for Blazor WebAssembly as a default choice for the app development, as it offers a capability of function without a server connection.

We have a basic idea about both the hosting models, their functions, and their utilities. Now we will look into some real-time examples, where we can see the clear differences between Blazor Server and Blazor Web Assembly.

Search Engines rendering capabilities

While developing the Blazor application we must remember that our application will be rendered and crawled by the search engines. It is a known fact that most of the search engines face difficulties while rendering the client-end functionality of a web application, typically developed in JavaScript.

Though, in recent years there has been increasing support for JavaScript, however, here we are talking about Blazor and WebAssembly. We must understand and see how Blazor Server and Blazor WebAssembly performs and supports different search engines. We can run both the applications and observe their results to understand this parameter.

Blazor Server – An application developed in Blazor Server will always output all the fetched HTML in the form of the source code. Here in the source code, the code for links can be seen on the left side of the page. This makes it wonderful for the search engines, as they can read the content of our web page without having to perform and execute client-side functions.

Blazor WebAssembly – It operates at a different level, where it loads only a template into the source code. WebAssembly takes responsibility for rendering of applications and that is the reason why the WASM applications are not good as far as search engine rendering is concerned.

Offline Support for Application

Here the biggest question is – What will happen with the Blazor application when it goes offline due to any network or system issue?

Blazor Server – For Blazor server applications, once the application loses the connection to the server, it becomes almost useless. In such events, the application throws and error and display an error message to the end-user, as shown in the below screenshot.

Blazor WebAssembly – Here, the situation is quite different, it offers a better functionality once the application loses the network connectivity due to any reason whatsoever. Once a WebAssembly application is downloaded to the browser, the end-user can continue to browse and use the application in a normal fashion, even after turning off the application. The WebAssembly offers a unique capability to run the applications in offline mode.

Scalability

It is an important factor, considering the current trend of application scaling across the tech world.

Blazor Server -  Here it is important to understand that if Blazor Server applications are to be scaled, we must scale their server part, the same way we scale a standard web server. Microsoft recommended that we need at least approximately 85 KB of RAM to cater to a single client. Microsoft has conducted several real-time tests and they came to the following conclusion, that how much a Blazor server can handle.

• Any server with a single CPU and 3.5 GB RAM and can handle 5k concurrent connections.
• Any server with 4 CPU and 14 GB RAM could handle 20k concurrent connections at any point of time.

Web Assembly – Here WebAssembly operates quite differently. It does not need any sort of scaling for the Client part as it is generally downloaded by the end-user and it runs in the browser itself.

Application Initialization -

Application initialization is an important aspect of any application. Here we are taking an example of "Weather Forecast '' application, that is usually shipped with Blazor. Here we will try to see how these applications initialized. We will use Google Developer Tools and make efforts to map the timeline of the homepage. We will click on the respective Counter link and see how both the hosting models function differently.

Blazor Server – In the below example, it is quite evident that Blazor Server loads CSS and HTML. Here, it is also evident that it also contains blazor.server.js (JavaScript file), that file is useful in initializing a connection to SignalR via web-sockets.

Here we can see that it has loaded 9 requests and has loaded them within 317 milliseconds. Now if we click on the Counter link, we may know how it is affecting the application timeline.

Here it is quite visible that there is no new network activity observed when we click on the given link in the Blazor Server application. The data is being pushed via an active SignalR connection, then the counter page can be requested via clicking on the link which is sent by the server. Here, the server returns the HTML for counter pagers by using the SignalR.

Blazor WebAssembly – Here, whenever we try to load any Blazor WebAssembly application, it must download all the applications into the browser. If we observe the current example, it has to load in 203 requests at a load time of 4.13 seconds.

Here we need to keep one thing in mind, that if the application is big in size, it will take more resources that need to be downloaded to the browser. The thumb rules say, the more resources, require longer application load time.

Now if we see that Counter page, it gives the impression that the initialization of WebAssembly application is more or less similar to the Blazor Server application.

However, the truth is different, WebAssembly applications offer better initialization. That is because unlike Blazor Server, the Blazor WebAssembly application has already been downloaded into the browser of the end-user and it does not have to interact with the server.

It also means that link clicks in the application are almost certainly going to load much quicker if we compare that with Blazor Server applications.

Server-Side Functionality –

This is an important aspect which clearly shows the difference between both the hosting models.

Blazor Server - If we look at the Setup and Program for a Blazor Server application, it looks like a standard ASP.NET Core Web API application.

// Program.cs
public class Program
{
    public static void Main(string[] args)
    {        CreateHostBuilder(args).Build().Run();    } 
    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();            });
}
// Startup.cs
public class Startup
{    public Startup(IConfiguration configuration)    {
        Configuration = configuration;    } 
    public IConfiguration Configuration { get; }
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
        services.AddServerSideBlazor();
        services.AddSingleton<WeatherForecastService>();
    }
     public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }
         app.UseHttpsRedirection();
         app.UseStaticFiles();
         app.UseRouting();
         app.UseEndpoints(endpoints =>
        {
            endpoints.MapBlazorHub();
            endpoints.MapFallbackToPage("/_Host");
        });
    }
}

Due to its similarity to the ASP.NET Core Web API, it offers an ability to add server-side tools, such as Entity Framework.

Blazor WebAssembly – Now, please take a closer look at the Program class defined in the Blazor WebAssembly application.

// Program.cs
public class Program
{    public static async Task Main(string[] args)
    {  var builder = WebAssemblyHostBuilder.CreateDefault(args);
        builder.RootComponents.Add<App>("#app");
        builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
         await builder.Build().RunAsync();
    } }

It is quite visible that WebAssembly offers a lot more slimmed down version of Blazor Server application. Though it offers support for dependency injection leaves a lot of many other aspects at the same time. It is important to add that server-side functionality can be added to Blazor WebAssembly application, to achieve that we must integrate it with a server-side application, such as ASP.NET Core Web API.

Blazor Server vs Blazor WebAssembly – Features

The following table may help you to make the right decision before indulging into Blazor application development.

Blazor Server - Ideal use case

Though Blazor Server can be utilized in umpteen number of scenarios, it is known for its meticulous performance and execution while developing and executing low demand public-facing applications and Intranet applications. Blazor Server offers an amazingly fast speed of application development, as it offers a unique hosting model which is obscenely quick, as almost everything is available on the server. While using the Blazor Server, we do not need separate API projects, and we can utilize the application services directly in our application components.

Blazor WebAssembly - Ideal use case

Microsoft’s renowned ASP development team developed and its prime objective was to bring a direct competitor to highly popular JavaScript frameworks. It offers almost similar capabilities and features, which makes it a robust alternative for anyone who is looking for something different from JavaScript.

Blazor WebAssembly also offers unique capabilities to develop Progressive Web Application, it also offers an out of the box PWA development template, which acts as a boon for the developers. It is important to know that while we use Blazor WebAssembly, we do not need to use .NET at the server-end. It means if we have a server-side backend code written in PHP, Node, or Rails we can still use the Blazor as the frontend component development framework without thinking twice, as Blazor WebAssembly will ultimately help us with the compilation of the static files.

Conclusion

Blazor was developed and launched by the Market Leader Microsoft, with a vision to create a robust competitor against the mighty JavaScript, which is ruling the roost for decades. Microsoft has offered a plethora of opportunities, features, and options for application development. It offers both the server-side and client-side hosting models, which has it's own set of advantages and disadvantages as well. However, it is important to note that both the hosting models offer the right set of capabilities to develop robust, scalable, and high-performance applications, which can give a run of money to any application developed using JavaScript framework. You can learn more about it from Microsoft's Blazor Site.

In case you sought any sort of support and consultation in making the decision of the right architecture model or design to develop your application via Blazor, then we can certainly offer the right kind of support to you. Our Blazor Experts at Arka Softwares can certainly help you decide the best Blazor tool and architecture choice for you and your applications.