Please Note: As of .NET Core Preview 8, server-side Blazor is now known as a Blazor Server App. Client-side Blazor is known as a Blazor WebAssembly App.
It has been a significant couple of weeks in the Blazor world. First there was the 0.5.0 release which gave us server-side Blazor. Then in the ASP.NET community stand up on 7th August, Dan Roth told us that the server-side Blazor model would be part of .NET Core 3.0.
Today I’m going to cover what server-side Blazor is. I’ll talk a bit about Blazors architecture. Then move on to how the server-side model works along with its pros and cons. Then finish off by talking a bit about how it fits in with the client-side model and how things will progress going forward.
Let’s get started.
What is Server-side Blazor?
I’m going to start by stating the obvious, server-side Blazor executes on the server. Now I’m sure anyone who’s used MVC will be asking themselves
S_o what’s the difference between server-side Blazor and MVC?!_
Let me tell you a bit more about server-side Blazor and hopefully I can answer that question.
For starters I’ve told you a bit of a half truth, server-side Blazor doesn’t actually run completely on the server.
The great thing about Blazors architecture is its flexibility. It has the ability to separate the execution of a Blazor application from the rendering process. This opens up a mass of possibilities for application development.
For example, Blazor can be run a in Web Worker thread with events coming in from the UI thread and Blazor pushing back UI updates. This would allow Blazor to be used for developing Progressing Web Applications or PWAs. Another option would be to develop desktop apps using Blazor with Electron. In fact the Blazor team already have a working demo of a Blazor Electron app which you can go and play with right now.
Now we know a bit more about Blazors architecture let me explain how Blazor server-side actually works.
The server will execute the component logic server side producing HTML. This is then compared, on the server, to a snap-shot of the DOM currently on the client. From this comparison the changes required to make the DOMs match are produced. These changes are then packaged up and sent down to the browser via the SignalR connection. Once at the browser the HTML changes are unpackaged and applied to the DOM.
When you interact with the application, say, by clicking a button. That event is packaged up and sent back to the server via the same connection. Where it will be processed and the resulting DOM changes will be sent back to the browser to be rendered.
Server-side Model Benefits
I’ve touch on a few of the benefits already, but let me go through them all properly.
.NET Core APIs
Because the application is running server-side you have access to all of the .NET Core APIs. If you were looking to convert a MVC application for example, you should be able to access everything you do in the MVC app in Blazor.
As I’ve mentioned previously, you will get that SPA feel with your server-side app. There will no no unnecessary page refreshes and the app will have a very rich interactive feel.
Much Smaller Downloads
In comparison to the the client-side version. Server-side Blazor has a much smaller download. This leads to significantly quicker startup times for your application.
Carrying on from the previous benefit, smaller download and the fact server-side doesn’t require WebAssembly means your app can be consumed by a wider range of clients. And as the main processing is done server-side lower powered devices can be targeted as well.
The current development experience with client-side is still very much a work in progress. And while it’s improving every release, you still can’t hit F5 in Visual Studio and get the normal debugging experience we are all used to. But that is not the case with server-side apps, you get access to all the great developer tools you’re used to.
Depending on how you architect it, it’s possible to write your Blazor app once. Regardless of which rendering model you intend to use, server-side or client-side. The app must avoid using synchronous JS interop for example. This is great for those who are more interested in the full client-side Blazor. They can start developing Blazor apps with the server-side model, then switch over to the client-side model at a later date. And switching can take seconds, it’s just a small change to how the app is bootstrapped.
No such thing as a free lunch
As with everything in life there are trade-offs. Server-side Blazor, at first glance, looks to be the best of both worlds. You can have all the benefits of executing your app server-side with all the nice UX of a single page app. While that is all true you are also going to have to weigh up the cost.
Because server-side Blazor needs the server to do the actual work, if it’s not available your app will stop working. This may not be a biggie depending on what you need your application to do. If you are converting an MVC app for example you already have this limitation. But if you are looking to convert something like an Angular app then you are going to be losing something.
While SignalR is very efficient there is still a lot of chattiness with the server-side implementation. This can lead to a slightly sluggish feel at times with server-side Blazor apps. Every time a user interacts with your application a round trip has to be made to the server to process the interaction. This may return DOM updates which have to be processed and applied client-side.
The server has to manage the connections to every client that is currently using your application. On top of this it is also responsible for keeping track of the state of each of those clients. We don’t really know yet how well server-side Blazor will scale with heavy use applications. This is something to keep in mind when planning your next app and considering server-side Blazor.
Persisting App State
A current short coming as of 0.5.1 is that if there has been no communication between the server and client the SignalR connection can be lost at which point the app will break. If this happens any app state will also be lost. Currently there is no nice story for developers in terms of maintaining app state. You must find your own way of managing things for now until the team put something in place.
What does this mean for client-side Blazor
For now it will continue to be an experimental project at Microsoft. But just to be clear:
The goal of the Blazor team is still to deliver the client-side model, that has not changed and will continue to be pursued.
The simple fact is that the client-side model relies not only on WebAssembly but also the efforts of the Mono team and their WASM .NET runtime. While progress is being made extremely quickly it’s not not quite there yet. AOT is not an option, there is extremely limited debugging, performance needs to be improved, download sizes are to big, etc…
The server-side model gives Microsoft a chance to get Blazor out there to people almost immediately. And as it runs on good old .NET Core it’s also got a solid base. It’s also important to remember that due to the Blazor architecture, with its separation of app execution from rendering, any developments made will benefit both models. So client-side is not going to get left behind.
I’m going to leave it there for now. I hope I have managed to give you a good overview of what server-side Blazor is as well as some of the pros and cons. If you have any questions then please post them in the comments and I will do my best to answer them.
Oh, and coming back to the question right at the start of this post, w_hat is the difference between server-side Blazor and MVC?_
I think my answer is, a lot.