The following is an article I wrote on behalf of Headspring – the original article can be seen posted here.
Blazor in context: The user imperative
As digital technology advances at accelerating rates, both external users and business software users expect websites to deliver more productivity and smoother user experiences. Excessive page loads, and the design limitations they impose, make a website feel significantly slower. Organizations investing in their user-facing experiences are seeing returns in terms of efficiency and user adoption/loyalty.
A single page application (SPA) delivers better UX and speed, but in the past, that has always meant more development time and a JavaScript-heavy frontend. But dotnet-heavy shops now have an intriguing option in Blazor, the new Microsoft front-end framework that leverages C# in the browser. If you’re thinking about enhancing your front-end experience, Blazor is probably on your radar—but is it the right framework for you? Let’s look at the concerns you might have when considering Blazor for your web apps, as well as the reasons you might choose it over other frameworks.
So how is Blazor different from Silverlight?
The first concern on everyone’s mind when they hear about Blazor is “Didn’t Microsoft try to do this with Silverlight?” This is a fair concern to have, but luckily they have learned from the past. With Silverlight marching towards the end of support, we can look back and ask what went wrong. The fatal flaw seems to have been built into Silverlight from the start: the reliance on a plugin. The assumption that users would opt to download it just to visit a website did not pan out for Silverlight. Plus, some browsers dropped support for plugins entirely. Blazor takes a completely different approach—it does not require a plugin or anything more than the browser you already have. Plus, not only does it work in all modern browsers, but it can also be configured to work in older browsers like Internet Explorer.
Some early-adopter anxieties
The other major concern is the immaturity of the framework. If you’ve ever been an early adopter of a certain technology, you know that it can be a double-edged sword. On the one hand, you get access to the latest and greatest features well ahead of the market, but on the other, you can sometimes find yourself downstream without a paddle. While Blazor is no different in this regard, it does have several mitigating factors going for it.
- First, it is a Microsoft framework that has been in development and beta testing for years leading up to its first supported release.
- Secondly, because of that beta period, there is already a community behind Blazor, providing support and building libraries for all your typical web client needs.
- Lastly, it draws inspiration from other popular front-end frameworks that came before it and reuses existing technologies, such as Razor, rather than completely reinventing the wheel. If your team already has experience with other frontend frameworks they will find that Blazor has a familiar, component-centric approach.
Now that we’ve explored some of the concerns with Blazor, what are some of the indicators that it’s a good fit for your project?
You can leverage your Razor page knowledge
The most obvious use case is if you are already a dotnet shop looking to greenfield a modern single-page web application or to migrate an existing Silverlight or MVC application. While MVC will continue to be a popular option, if you are already using Razor pages, you can get a smooth, zero-page-refresh experience with little additional effort. This creates a better experience for your users while at the same time reducing the burden on your servers.
Blazor can enhance productivity
But even if C# isn’t your bread and butter, there is significant productivity to be gained by leveraging Blazor as your web framework. By using the same language for the back- and front-end code, you can avoid duplicating effort and reuse the same libraries, the same API models, and the same business logic. Plus, how many times have you had to work on a project where the front-end models no longer matched the back-end or validation on the front-end was missed on the back-end, thus leaving security vulnerabilities in your API. By using one language, you can reuse your code and know you’re covered.
Another advantage of using a single language is the ability to build bigger apps with smaller teams, faster. Standardizing the language reduces the necessity for specialized developers and makes it easy for everyone on your team to be a full stack developer. Dropping context-switching and waiting on someone else to do their part before you can do yours can save a ton of time when developing a feature. On top of all of that, you can use the same tools throughout the stack, onboarding is much faster, and your team can spend more time getting good at what they know rather than constantly needing to learn new versions of the same thing.
There are many factors to consider when choosing a framework for a modern web app. While each specific application will have its own unique factors to consider, you should now have a good starting point when evaluating Blazor as a potential solution. Whether creating something new, replacing an existing page-load-per-click website, or even replacing another SPA that has become hard to maintain—Blazor may help you achieve the productivity gains and enhanced user experience you need in order to stay ahead of the curve.