In this post I do a quick comparison between client side Blazor and server side Blazor.
In my previous article I ran an experiment with client side Blazor. In this article I want to explore server side Blazor to see how it compares to the client side counterpart.
As you may recall, the client side version relies on WebAssembly to run the .Net framework directly in the browser. In theory this is really cool, but the cost of downloading all the .Net dlls is currently far too high for it to be practical. My simple demo application resulted in a payload of 5MB, which is way too big even on a fast connection. You can try the application here to see what I mean.
To be clear, server side here is not the same as Asp.net server side approaches like Webforms or MVC razor views. Instead it refers to a server side execution model for Blazor. The application still feels like a SPA, but instead of executing .Net code in the browser, the code actually runs on a server.
How is the browser updated if the code runs on the server?
Traditional server side apps like MVC require a full page refresh to update the browser, but Blazor is conceptually more like an Ajax application when it comes to view updates. However the interface is much more chatty than your average Ajax application. Basically the browser receives incremental view updates from the server through a web socket connection. Every time the view needs to be updated, a request is made to the server through a socket connection (SignalR). After the request is executed on the server, the incremental view change is returned to the browser.
An obvious concern from this approach is scalability from a drastically increased number of incoming requests from connected clients. In my example the incremental payloads are in the order of 1k, which isn’t huge, but you still need a stable network connection. Offline mode is not supported since any view update requires a server request.
Porting From Client to Server
Moving to server side hosted Blazor is just a matter of changing some configuration. Otherwise the application code is identical. I was able to port over the client side demo application in about 10 minutes, which is great!
I have deployed a version of my server side app here. The first thing you will notice if you compare it to the client side version is a drastically improved startup time. The client side version really suffers from the high tax of having to download the whole universe of .Net dlls before initial render.
For the most part I find that the server side version performs well. I have noticed slight delays in some cases when expanding nodes in the treeview, but 99% of the time it feels seamless.
It’s still very early for Blazor, but I am super excited about this concept in general. Looking forward to see what the Blazor team has for us in the future.