Blazor In Action
I have written a couple of prior posts on the Blazor framework (see: https://www.garudax.id/feed/update/urn:li:activity:6371008276703825920 and https://www.garudax.id/feed/update/urn:li:activity:6383699258406682624 ). It’s been a while since the last post but I have been keeping up with what is happening in the world of Web Assembly and in specific with the Blazor framework. Recently Microsoft took Blazor from an experimental platform to an actual product. Previews are now available and stable enough to begin to really start investing more development time. To continue exploring Blazor I took up the task to port my website (www.stepquest.com) from Angular to Blazor. There are plenty of articles and blog posts to provide “get started” and “how-to” details (e.g. https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-3.0) so, in the interest of brevity, I will try to simply summarize my experience.
Since the Angular version of the Stepquest website was built on basis of a WrapBootstrap template (www.wrapbootstrap.com) I wanted to keep that template in the new Blazor based web site. It turned out to be a really great experience since the WrapBootstrap template used employs more traditional projects structures (e.g. Angular in the browser and Asp.Net MVC on the server-side) and also many JavaScript library dependencies. This gave me a great opportunity to work through Blazor’s structural capabilities and JavaScript interop capabilities for legacy and/or backward compatibility purposes.
Structure of the Blazor project:
Currently Blazor has two hosting models (i.e. Client-Side and Server-Side Blazor: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0). While each hosting model has its pros and cons I chose Client-Side Blazor for my website for no other reason than it was what I wanted to explore.
Blazor allows for a flexible project structure to meet most any need. I find it quite intuitive to abstract, for example, view models, view components and application state so they can be used in concert across the entire application (both server and client side). See:
https://docs.microsoft.com/en-us/aspnet/core/blazor/dependency-injection?view=aspnetcore-3.0
https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.0
Also, since Blazor can be hosted anywhere a Blazor app could run, in theory, as a Windows or Linux desktop application or a game console application. I now get all the great expression and strong typed goodness of C# across all my application with incredible reach! Pretty awesome if you ask me as we have never really had widely accessible framework quite like this before!
But wait. There is more!
Since now I could do everything in C# does not mean I should or have too. Almost all websites and website enablers today employ JavaScript and I want to take advantage of their goodness. With Blazor this can happen. Blazor’s JavaScript interop is pretty fantastic and just getting better (see https://docs.microsoft.com/en-us/aspnet/core/blazor/javascript-interop?view=aspnetcore-3.0). While there is admittedly some work to port/integrate Blazor’s JS Interop I did not find it difficult or awkward. Tying in JavaScript libraries was straight forward, and the documentation was actually pretty good. It just worked!
But wait. There is more!
Blazor is all open source along with Asp Net Core. There is an extremely active community on GitHub (see https://github.com/aspnet/AspNetCore). I find this a great community for learning and encouragement. Everyone seems to want to make Blazor better. Simply awesome!
To Summarize:
After going through this experience, I was left with the distinct impression that Blazor is far easier and far more efficient to implement and maintain than any client-side JavaScript framework I have utilized to date (e.g. Angular, React or Knockout). The main reason is the vast reduction is framework overhead. I no longer need to be saddled with learning the intricacies and foibles of a server-side framework and a client-side framework. I now have just one framework for structure and code project interactions. For example, I am no longer required to build/scaffold view models in C# for the server-side and Typescript on the client-side. I can now have my view models in one language and reused everywhere. If nothing else, that capability is enough for me to say Blazor is the future. While client-side JavaScript frameworks are super sophisticated and have helped immensely to create some amazing applications their complexity and overhead will make it hard to chose them where there are alternatives like Blazor.