The plethora of front-end Single Page Applications out there share one thing in common: a distinct division between client and server in both code and environment. Typically, the client code is JavaScript, and the server code is something else entirely. They both live in different places, don’t share, and only communicate through HTTP messages. But what if there was a better way? What if the client code and server code could not only live under one roof but learn to share and even speak the same language? A few years ago, that might have sounded like high fantasy. But that was all before Blazor came along.
What is Blazor?
Microsoft Blazor is an exciting web framework that has been in development since 2018. The idea is to allow a more unified approach between front-end client and backend server codes. Developers can build web applications using one of five different approaches: Blazor Server and Blazor WebAssembly are currently available, while Blazor PWA, Blazor Hybrid, and Blazor Native have been announced. Developers can build web applications using .NET Core, C#, HTML, and JavaScript in any flavor. Blazor is based on components that can have JavaScript interoperability for DOM manipulation or utilizing browser features. Components are based on Razor components and consist of a mix of HTML and C#. C# largely takes on the role normally occupied by JavaScript and controls the behavior of the web page. Components can be reused, embedded in other components, and inherited from other components.
Advantages
Much like other UI frameworks, Blazor allows for building robust, interactive web applications. The difference is that, unlike other JavaScript-based frameworks, Blazor allows the application to share code between the front end and backend since C# is used on both sides. With this approach comes several advantages:
C# vs. JavaScript
I don’t want this post to turn into an in-depth comparison of two different programming languages but using C# over JavaScript or TypeScript provides several advantages. For one, C# is a strongly-typed, class-based language, while JavaScript is weakly-typed and prototype-based. While one type of typing or inheritance style is not necessarily better than the other, there are several advantages to the former paradigm. Since strong-typing is very rigid and inflexible, the compiler has a better time understanding the code and can catch far more errors in compile-time than with JavaScript. Additionally, C#-only code allows IDEs to provide better IntelliSense than JavaScript or TypeScript ever many of the same reasons.
What if the client code and server code could not only live under one roof but learn to share and even speak the same language?
A More Unified Project
One of the main selling points of Blazor mentioned above is that the front-end and backend of an application can share many of the same code and libraries. Since Blazor is built on top of .NET Standard, client code can make use of any existing .NET library. Furthermore, all of the application logic can now be shared across client and server. This means both sides can now make use of the exact same classes, services, and controllers. This leads to much less duplicated code and logic across both sides since they can both pull from the exact same resources.
Blazor makes use of Razor components. Anyone familiar with that mix of HTML and C# will have no problem adapting to Blazor. Razor components are flexible, reusable, testable, and shareable. Also, Blazor applications can be built using Visual Studio. VS is a popular and very powerful IDE also built by Microsoft. Since both are Microsoft products, you can imagine they work very well together.
Availability
As mentioned, Blazor is currently available in two hosting models: Blazor WebAssembly and Blazor Server. Each will be detailed below. Additionally, there are plans for Blazor PWA (which supports progressive web applications) and Blazor Hybrid (a platform-native framework that renders using web technology). Blazor Native, a platform-native framework that renders a platform-native UI, is also being considered. The hosting models provide great flexibility and fit most situations.
Support
Blazor is supported by most major web browsers, including Apple Safari, Google Chrome, Microsoft Edge, and Mozilla Firefox. But in reality, any modern web browser that supports WebAssembly is able to run a Blazor application.
Disadvantages
Unfortunately, nothing is perfect, and Blazor is not without its faults.
Future
Microsoft has invested a lot of resources into developing Blazor and seems to have a lot of plans for its future. However, it is had to trust a young framework when projects like this are dropped at the tip of a hat by large tech companies. Google has killed off many beloved features, and people are still sore about how Microsoft pushed Silverlight hard, only to unceremoniously drop it with little warning. Developers have a long memory and are, with good reason, slow to fully commit to new technologies like this. This can make it hard.
Official Support
Blazor is now officially part of .NET 5, which is a terrific sign for Microsoft’s commitment to and investment in the technology. However, Microsoft also decided not to create their own official component library, as they have with NuGet and C#. Instead, they chose to leave component libraries to third-party developers. While this can always change, it does send a bit of a mixed message. Is Microsoft genuinely committed to the framework? Is this decision merely to focus resources on developing Blazor itself? We’ll never really know until it goes one way or the other.
Maturity
Blazor is still very young, having been around only four years. While both Blazor WebAssembly and Server have reached general availability and are considered production-ready, they are largely untested and not nearly as mature as Angular or React. Since Blazor is so young, Microsoft is also continuously updating the framework and making significant changes, leading to headaches in a production environment. There are also no large projects that made use of Blazor. Since it has such a short track record and few accolades, it can be hard to trust as the basis for your larger projects.
Microsoft has invested a lot of resources into developing Blazor and seems to have a lot of plans for its future.
Hosting Models
Blazor currently has two hosting models that are production-ready. Each excels in certain aspects, so choosing the correct model for the project requires great thought and consideration.
Blazor WebAssembly
The Blazor WebAssembly model is the traditional Single Page Application variant of Blazor. Like Angular, the entire application is loaded to the browser and runs natively on WebAssembly. This payload includes .NET Assemblies (compiled C# and Razor files) and the .NET runtime. The browser bootstraps the .NET runtime and configures it to load assemblies for the application. JavaScript interop is used to handle any DOM manipulation and browser API calls.
All work is offloaded to the client, and the application can leverage all client resources and capabilities. Because the entire application exists in the client, there is no server-side dependency. This means Blazor WebAssembly projects can be standalone or hosted and serverless deployment is possible through either a CDN or Docker container.
However, Blazor WebAssembly is not without flaws. Because the application uses WebAssembly and runs entirely on the browser, it is limited to the browser’s capabilities. Considerations may have to be taken to make the application completely cross-platform. Additionally, like most SPAs, Blazor can take a long time initially due to the large initial payload. Blazor does try to optimize the size of the payload, however. Finally, .NET runtime and tooling support is less mature.
Blazor Server
Blazor Server is a bit of a hybrid between a traditional web application and a SPA. In this case, Blazor lives mostly on the server, including the .NET runtime, and the client UI exists as a thin shell on the browser. Any events on or updates to the UI are handled by a SignalR connection to the server. The UI applies updates to the rendered components based on instructions and the payload sent back by the server. Rendering logic is handled completely on the server, and the UI handles how they are applied, thus decoupling the two. JavaScript interop calls are handled by SingalR.
Since Blazor Server has a much smaller initial payload, the application loads much faster than with WebAssembly. .NET and C# code do not need to be served to the client and only code to render the view and update the view is necessary. Additionally, since the runtime and code are all server-based, all server capabilities can be leveraged and .NET tooling and debugging work as expected for any regular web application.
However, since every single interaction by the user and update to the view require communication with the server, latency can be much higher. Additionally, since every event and view update require the server, the application has no offline support. If the SignalR connection fails for any reason, the application will simply stop working. The server is also now responsible for maintaining an active connection to every client and must act on every action taken by each client. This can put a great load on the server and make scaling for many users difficult. Finally, because an active SignalR connection is required, serverless deployments are not possible.
Conclusion
This has been a high-level overview and description of Microsoft Blazor, an exciting new technology in the web UI framework world. Blazor attempts to bridge the gap between client and server and provide the developer with a more unified platform for creating web applications. With two production-ready models and many more to come, Blazor has a bright future. I am already impressed with what Blazor has accomplished and am excited to see what comes next. Personally, I don’t think the technology is quite ready for prime time but could very well be in the next few years. Will we one day see Blazor compete with the likes of juggernauts like Angular or React? Only time will tell.
Interested in diving deeper into Custom App & Web Development? Click here to read more blog posts from Tallan. We also have multiple live educational webinars centered around our funded App Innovate opportunity, providing attendees with a chance for direct Q&A with our experts. Click here to view our current calendar.