Should we use Blazor for developing our solutions moving forward?

What is Blazor and why use it?

First off Blazor is a Microsoft based framework for developing SPA (Single Page Applications). The core objective of Blazor is to allow developers to use c# to do full stack web development.

So by using Blazor you actually don't need to use ANY javascript IF you don't want to, (you CAN use Javascript with Blazor if you REALLY want to). It's designed to replace javascript frameworks such as React.

For the Sulware development team, it's actually the dream scenario, as we are fundamentally a c# development company when it comes to our web bases solutions, (we still use Java and Swift for dedicated app development)

So the key here is to really have a web site user experience that offers a super fast and smooth UI without the need for any javascript framework and JUST using c#, html, and css. This will result in a much more efficient and maintainable project.

There are two types of Blazor solutions:

• Blazor Client and Blazor Server.
• What's the difference?

Well, Blazor Client fundamentally runs all the c# code on the client side. When you develop your front end html with c# code driving the logic, none of that c# code runs on the server. It's all downloaded to the client and run from there. This results in lightening fast user interactions with buttons and general UI components in comparison to say a typical Razor/ server side page that required user interactions to be processed back on a server resulting in large data responses going over a HTTP connection.

In order to do this the .net Framework actually needs to be downloaded to the browser and run within the browser. This is done using WebAssembly which is a virtual machine that runs within a compliant browser. As of at Februraty 2022 most modern browsers fully support WebAssembly, (https://webassembly.org)

The Blazor Client app begins it's interaction with the browser first off downloading the .net framework and all supporting application assets to the client machine and THEN the client can start using the app. This means initially there's a big up-front load cost for the client, so initial load times can be slow (we're talking 2MB minimum download sizes for the base .net Framework alone and after that it depends on how big the client application items are (i.e. Compiled app dll's, css, asset files etc). This shouldn't be a massive problem in todays broadband environment but still, it can be an annoyance.

Once that initial download is done though, everything is lightening fast on the client. Whenever the client needs to query backend databases it uses REST api calls over HTTPS to get the data it needs, or to push the data it needs to persist on the server. So that means the server side element of the solution is built around REST API calls which will have relatively small JSON based responses.

Also, Blazor clients are capable of running offline, which is an attractive proposition, and they also lend themselves quite well to PWAs (Progressive Web Apps, a way to turn a website into an app that can be run AS an app in iOS and Android devices and even be deployed to App Stores).

Blazor Server works differently.

From an application build perspective Blazor Server and Clients look almost identical in project file structure and the same fundamental code base is used. The difference is in the project setup files.

Blazor Server apps work in almost an identical manner to normal Razor page sites. All the c# code is run ON THE SERVER, not on the client. However, calls to the server from the client aren't done using HTTP like traditional Razor pages, instead SignalR websockets are used. This is how Blazor Server applications remain very fast. Only delta UI state change requirements are sent from the server. So for example say a client page is showing a paged list of results in a table, when the user hits the next page button, the client sends a TINY button click request to the server over signalR, and the server sends back JUST the actual list contents to the client - no headers, footers, CSS, images etc. Literally just the data that's required. The data packages flowing to and from the server are tiny, relatively speaking resulting in that "almost native" fast UI experience.

So Blazor Server looks like a very attractive option to develop our typical Sulware based apps moving forward. However, there is a potential kicker here. SignalR is a websocket based technology, meaning that on initial load of a page, a websocket is opened between the client and the server, and the server needs to maintain that websocket. (Typically modern servers can support tens of thousands simultaneous open sockets). All state is maintained on the server for this particular session with the client. So there can be a lot of data that needs to be potentially maintained for any single client. In a high traffic scenario, depending on how we are holding data on the server for a client, we could find the server becomes over stressed quite quickly. So, great care needs to be taken regarding how we manage data required for client requests. This needs thought, (e.g. Don't get massive lists of data from databases and store in variables, instead just get the required client page of data). As a side to this Azure webapps are setup pretty well to handle Websockets, and so the webapp can be easily setup to auto scale when required.

Blazor is a VERY interesting proposition for us. The idea of developing full stack applications using just C# (and html and css) and not having to use any javascript at all is really the dream for us at Sulware. For us, javascript has always been a messy and badly maintainable way of developing web based frontends but up to now you really can't develop any meaningful UI's without Javascript. Blazor potentially eliminates javascript from the stack.

So the key question now is CAN we build future versions of our core CMS and future client solutions using Blazor, OR should we just switch to Razor pages and continue to use javascript where required?

Also, at this point we should bear in mind that up to now our applications have been MPA's (Multi-Page Applications) and so the additional question is hould we switch to PDA based solutions?

At this point we're still evaluating. However, Blazor has come a long way in the past couple of years from an initial experimental framework to a mature supported framework which Microsoft has fully committed to. From Microsofts perspective, Blazor is here for the long haul.