In this post, I will share with you on my journey on how I started my blog with Blazor WebAssembly & my future plans. I have always wanted to start my own blog by sharing experience on software development along my career path. It's always the number one question comes in mind, "Which technology/platform should I use?". In my opinion, choose what best fits your requirements. For me, I'm creating this blog for my personal hobby and would want to explore blazor technologies along my way.

Why did I choose Blazor?

Personally, I have been always developing software's revolving with C# .NET and would always keen to explore Microsoft technologies. What a better way to start blogging than now with the introduction of Blazor. In most real-world scenarios, we opt to use Angular, React, and Vue.js for front end development due to the fact that it has better developer/user experience which I do not disagree at this point. With Blazor, I can be a full stack .NET developer. Sounds interesting?

Which Blazor hosting model fits my requirement?

There are two types of hosting model, Blazor Server & Blazor WebAssembly. I went with Blazor WebAssembly due to my long terms goals with my blog. It's not a difficult decision to make because of the nature of how different hosting models fits on case by case basis.

Here's the requirements that I needed:

• Single Page App (does not need ASP.NET Core on the server)
• Faster loading (No SignalR dependancies exchange with server)
• Offline support (CLR & Assemblies are downloaded to client browser under WASM)
• Works in all modern web browsers, including mobile browsers
• Blog posts will be part of project structure because I find it's easier to create or edit posts.

How is ASP.NET Core MVC different from Blazor?

I have worked with numerous amount of MVC projects and always my go to project when I needed my project with UI where it provides controller routes with Views. The views also leverage Razor syntax. Each request made in MVC will receive a full HTML with CSS, images, Javascript and back-end data over each requests made.

In Blazor, it leverages the same Razor syntax but the key difference here is that it does not re-render Views and only render specific components called Razor components. After the component is initially rendered, the component regenerates its render tree in response to events. Blazor then compares the new render tree against the previous one and applies any modifications to the browser's Document Object Model (DOM).

Therefore, the benefits here is that you will not require to re-render the page each time when page is requested. Only when it has changes. Perfect!

How did I get started?

In this sharing, it's not about how to create Blazor WebAssembly project from scratch. Microsoft have built step-by-step guide on how to create your first Blazor project right here. Therefore, this post will explain on the underlying project structure & some tips to ease your understanding for Blazor WebAssembly.

First of all, believe me below are all the level of folder hierarchies I needed for my blog with Blazor:

Before running locally, run below command once in Windows/Mac environment to trust HTTPS locally for .NET Core

Once you have succesfully setup the entire project, it's now time to test it out locally. Open your preferred terminal and run the following command:

Debugging experience

The most interesting part that I've noticed is I went on to inspect Chrome developer console and found the below screenshot on application startup which provides logs to application overview: A typical .NET debugging will be putting breakpoints on application and running F5 command on Visual Studio/Visual Studio Code. If you see the above logs, I was keen to know what's with Debugging hotkey SHIFT + ALT + D in windows. Once I hit the debugging hotkey, I was redirected to this page below: If we follow the steps accordingly as the image above, a new Chrome window will be launched and you can hit SHIFT + ALT + D again. Once you done that, you will be directed to the page below where now you can debug .NET codes via Chrome Dev Console. That's amazing!! If we look closely on why we are able to debug .NET codes directly via browser is because by using WebAssembly, it will download CLR & assemblies of .NET and compiles it under Javascript Interop. Therefore, we will be able to debug .NET codes directly from browser. Use cases like debugging in a test environment without needing an IDE.

Resource size

As you can see, a typical simple Blazor .NET application are loaded with 8.65 MB resources. If we narrow it down further, you will notice all the .NET dll are downloaded to the browser and cached which contributed on the huge size of the resource. When it comes to situations where you have slower network speed, Blazor WebAssembly can be painful to load. However, it's also mentioned that published applications will be significantly smaller. Here's why with the help of compression algorithms like Brotli & Gzip.

In closing

Overall, I'm very happy how Blazor WebAssembly provides an end-to-end experience with .NET without having to write a single Javascript code and given that it has cleaner project hierarchy is a huge win for maintainability. Although the resource size & lacking of hot reload experience is a downfall now, but it will only get better as with the total attempt with Blazor is a huge evolution for full stack with .NET. If you would like to view the source codes, please feel free to view it right here.