Introduction
At this point we’ve all heard of Blazor. But when people first start out with Blazor, the analysis paralysis of picking between the types of Blazor projects can keep people from picking it up quickly—and being able to quickly dive in and have something up and running is one of the primary benefits of using Blazor in the first place.
My hope with this article is to provide a simple understanding of the differences between Blazor Server and Blazor WebAssembly, and give you the knowledge to pick the right tool for the job.
Both Blazor project types use the same component-based structure for writing web applications. If you’ve ever used React, you’ll understand what this looks like. Each unit of work or piece of UI is broken up into individual components, and components can be composed together as bigger, more complex components. In Blazor, we write these as Razor Components (.razor) which allows us to weave HTML and C# within the same code file. It’s great to work with and allows for very dynamic and maintainable UI components.
Blazor Server or WebAssembly. Which one is better?
This question gets asked a lot, but when it comes down to it, it’s not really the right question to ask. They are both amazing in their own regard, but it’s important to understand that they are very different fundamentally. A better question to ask is, “Which one is better for my situation?”
Blazor Server
Blazor Server, at its heart, is an ASP.NET Core server-side web app. The entire application runs on the server and the pages/components are rendered on the server before being sent as HTML to the client.
Blazor Server is very unique, and to my knowledge is the first technology to do things the way it does.
When a user connects to your Blazor Server web app, a SignalR connection is established between the client and the server. Every UI interaction from the user is sent as a small packet via this SignalR connection to the server. Every update or redraw of the UI is sent by the server to the client via SignalR.
This connection is maintained throughout the entire session, and if the connection is broken for any reason (exceptions/errors, connection issues, server restarts, etc) the user must refresh the page to re-establish the SignalR connection—otherwise the app will not be functional.
This is a very unique approach to web development. It allows us to make highly dynamic, flexible and responsive Single-Page-Applications (SPAs) that are entirely server-side applications.
Pros
- Data access is simpler. You do not need complicated API authentication schemes and session security to handle data access within your application. This is a server-side app after all, you can use an internal API or just use the Repository Pattern directly within your Blazor project.
- The code is processed on the server before the client machine gets any code, so they do not have access to the C# code from the browser. This again makes security, authorization, and data access much simpler endeavors
- Because of the previously mentioned points, Blazor Server is very easy to work with. You can jump in and work on your application very quickly and without many roadblocks.
These are very big benefits to consider. As a developer you can write a very feature-rich app quickly, while still following best practices.
Cons
- As previously mentioned, a SignalR connection is maintained for each individual client connected to the web app. These connections have a slight overhead on the server and can start to get expensive at large scale. If your application must support a very large number of concurrent users, it’s definitely something to consider. (Most applications will not see the kind of scale where this will matter.)
- Since UI interactions are reliant on a socket connection between the client and server, latency due to poor internet connection or physical distance from the server can negatively affect the experience of the user. Users with high latency may experience a noticeable lag in the UI interactions or will have a generally unpleasant experience. If your application will have a very diverse global reach, this will be something to consider.
Blazor WebAssembly
Blazor WebAssembly works very differently than Blazor Server. The entire application, along with its components and dependencies, are sent to the client. A very light-weight version of the .NET Runtime is also sent to the client. The Blazor application is then run entirely by the client’s browser with the help of WebAssembly.
This model of execution allows for a very pleasant user experience, since the UI interaction is not at all dependent on a persistent connection to the server. The client’s machine is doing all the work, so there is no server load to speak of when it comes to serving up the app to a user. In fact, you can even host a Blazor WebAssembly app entirely as a static website on a service such as Netlify, GitHub Pages, Azure Static Web Apps, etc. without writing a dedicated web server.
Pros
- Scale. Blazor WebAssembly apps can achieve arbitrary scale because the server is not running the application, the client is. This model allows for scaling to a high amount of concurrent users cheaply.
- Blazor WebAssembly apps can work offline or be written as PWAs (Progressive Web Apps)
- Performance is generally very good and offers a great user experience because the application is running on the client’s machine as opposed to a server
- Since you don’t need a dedicated server running and maintaining active user sessions, hosting a Blazor WebAssembly application can have a significantly lower cost.
Cons
- Data access and security is more complicated, since this application will be running entirely on the client side. All data access must be done over public APIs, which means that if you have user-specific or session-specific data, then the API auth and security must be managed. Additionally, the client will have access to your code (which is true of all client-side web frameworks) so you have to be aware of this while developing your app.
- Relatively big download size for the user. Initial app load time may take longer while the client’s machine downloads all the necessary files for the application to run. This isn’t unique to Blazor however and it’s somewhat common among front-end web frameworks to be a bit heavily front-loaded.
- WebAssembly is not supported by all browsers. It is a W3C standard so all modern standard-compliant browsers do have support or will be including support, but legacy browsers will not support this technology.
Summary
There are many more points to consider with each project type, as Blazor is very complex and full of nuance. But hopefully this article will provide a fundamental overview of both project types and what you should consider about each of them.
To summarize, you should consider picking Blazor Server for:
- Intranet/internal applications
- Apps that don’t expect to have a massive concurrent user-base
- Apps where you want to have the full support of a .NET Core server behind it, and all the tools and features you get with it
And Blazor WebAssembly for:
- Apps that expect to have very large scale with lots of concurrent users
- Apps that can be used offline or with an intermittent connection
- Apps where performance might be a concern / users might be accessing your app from different parts of the world
Hope this information has been helpful. Stay safe and happy coding!
Gabriel HenaoPosted May 13, 2023, 9:52 PM
This part : "sensitive data and business logic are downloaded and executed on the client side, making it more vulnerable to malicious attacks" does not happen if your Blazor client application is designed so that any needed business logic is processed in the backend (typically through a REST API) and then the client just sends a request to the backend to validate / process any business logic. This is true also for client applications made with Angular, React, Vue, etc. Even with Aspx pages is the same: If all the business logic is located in what is called "Code behind", it means that it needs to be processed in the backend. But anybody may decide to render JavaScript with business logic that will go to the client side (The browser) and therefore be exposed.