Original post here
This will be my first attempt at writing an article over something that I am learning on the way. Please be kind. I do think the best way that a person can learn something is to dive in and try and describe it another way, without diverting from the original definition. I am actually utilizing Blazor in an enterprise setting with my current position, so I am looking forward to learning about Blazor as my next step as a developer.
This article will cover some of the basics of Blazor, as well as an entry point for a series of future articles. What I plan on covering in this article:
What is Blazor?
What can Blazor be used for?
Blazor Hosting Models
Blazor Architecture
What do I plan on this series:
Blazor WASM
Blazor Server
Blazor Components
Data Binding
Routing
Dependency Injections
Lifecycle Methods
Invoke JS Functions
View Logic Separations
Forms and validation
Server Side Rendering
Client Side Rendering
What is Blazor?
So let’s get into it, what is Blazor. Blazor in of itself is Microsoft’s vision of a frontend framework. Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries. And we need to remember that Blazor is a feature of ASP.NET, so it can utilize other libraries of the .NET realm.
What can Blazor be used for?
Like I stated before, Blazor is part of Microsoft’s vision to allow it’s community of C# developers to continue in their route to write applications in C# from the backend to the frontend. Blazor allows for C# developers to limit their need of JavaScript. With that being said, there is still a need of JS in Blazor apps, more so in the JS Interop form, but not in as much as it was previously. Blazor should be categorized, and rightfully so, as a SPA framework. Microsoft took the concepts of other SPAs like Vue and React to make Blazor. Let’s build our applications in reusable components that can be utilized across our app(s).
Being able to code in majority of one language throughout an application’s life cycle, as well as building reusable frontend components so that I can keep up with the DRY philosophy seems like a dream. For these two reason, Blazor is your answer, and this is what Blazor can be used for. If you are strong in your confidence of ASP.NET and Razor page syntax, Blazor will be your new favorite toy to breakout and play with.
Blazor Hosting Models
There are two hosting models new developers to this arena need to know about: Blazor Server, and Blazor WebAssembly. Dependent on the structure of your needs for an new application will depend on the hosting model that you do.
Blazor Server:
With this hosting model, the app is executed on the server from withing an ASP.NET Core app. UI updates/changes, as well as some JS calls are handled over SignalR connection.
There are a lot of benefits from using this model:
Download size is significantly smaller that a WASM (another name for WebAssembly)
The app takes full advantage of server capabilities, including use of any .Net Core compatible APIs
.Net Core on the server is used to run the app, so existing .Net tooling, such as debugging, works as expected.
Thin clients are supported. For example, Blazor Server apps work with browsers that do not support WebAssembly and on resource-constrained devices
The app’s .Net/C# code base, including the app’s component code, isn’t served to the client
There are some cons of Blazor Server hosting:
Higher latency usually exists. Every user interaction involves a network hop
There’s no offline support. If the client connection fails, the app stops working.
Scalability is challenging for apps with many users. The server must manage multiple client connections and handle client state.
An ASP.NET Core server is required to serve the app. Serverless development scenarios aren’t possible.
Blazor WebAssembly(also known as WASM):
If Blazor Server runs on the server, you can safely assume, correctly so, that Blazor WASM runs on the client side inside the browser. This allows your site to be deployed as static files. Despite this, Blazor WASM apps will not directly run from the local file system due o the browser security restrictions.
Some of the benefits of Blazor WASM hosting:
Blazor WASM can work offline. When the network connection to the server is lost, the client app can continue to function. We can utilize sessionStorage/localDb/IndexedDB for “saving” items so once the network comes back up, the client app can talk to the server. Client resources and capabilities are fully leveraged.
It can also quite easily run as a Progressive Web App, which means the client can choose to install our app onto their device and run it whenever they wish without any network access at all.
With code running on the client’s machine it means the server load is significantly reduced.
An ASP.NET Core web server isn't required to host the app. Serverless deployment scenarios are possible (for example, serving the app from a CDN).
There's no .NET server-side dependency. The app is fully functioning after it's downloaded to the client.
Some cons/downsides to Blazor WASM hosting:
The blazor.webassembly.js file bootstraps the client application. It downloads all required .NET DLL assemblies, which makes the start-up time of the application slower than server-side.
The Mono Framework interprets .NET Intermediate Language so is slower than running server-side Blazor. Ahead-of-time (AOT) compilation is planned for a future release.
Blazor Wasm does not yet support more than a single thread, so all processing occurs on the UI thread – although calls to servers / JavaScript etc occur asynchronously, so do not block the UI’s responsiveness.
Additionally, Blazor Wasm only works on newer browsers and is not search-engine friendly (unless we enable server-side pre-rendering).
Download size is larger, and apps take longer to load.
.NET runtime and tooling support is less mature. For example, limitations exist in .NET Standard support and debugging.
Blazor Architecture
Traveling backwards a bit, Blazor in itself is strictly a client side web UI framework in nature to JavaScript frameworks like Angular and React. Blazor handles user interactions and renders the necessary UI updates. Blazor isn’t based on a request-reply model. User interactions are handled as events that aren’t in the context of any particular HTTP Request.
Blazor apps consist of one or more root components that are rendered on an HTML page.
How the user specifies where components should render and how the components are then wired up for user interactions is hosting model specific.
Blazor components are .NET classes that represent a reusable piece of UI. Each component maintains its own state and specifies its own rendering logic, which can include rendering other components. Components specify event handlers for specific user interactions to update the component's state.
After a component handles an event, Blazor renders the component and keeps track of what changed in the rendered output. Components don't render directly to the Document Object Model (DOM). They instead render to an in-memory representation of the DOM called a RenderTree so that Blazor can track the changes. Blazor compares the newly rendered output with the previous output to calculate a UI diff that it then applies efficiently to the DOM.
Components can also manually indicate that they should be rendered if their state changes outside of a normal UI event. Blazor uses a SynchronizationContext to enforce a single logical thread of execution. A component's lifecycle methods and any event callbacks that are raised by Blazor are executed on this SynchronizationContext.
I believe that this is a good overview of Blazor for now, and where this article comes to an end. I hope that you found this useful, and keep a look out for my other articles related to this one stated previously. If you have any questions, please comment below and I will reply back. The same goes for emails.
Oldest comments (0)