As with any technology, you’d be foolish not to be concerned about moving your organization to Blazor. Let’s clarify what’s worth worrying about. Also: Why you shouldn’t worry.
But it’s not just code: Because it’s “just another” .NET toolset, Blazor lets shops share expertise and toolsets across the whole application. Azure DevOps, for example, has (through Azure Pipelines) supported Blazor since 2019. Lately, because Blazor upped the stakes for Microsoft to develop an Ahead of Time solution for .NET, Blazor is actually driving Microsoft’s efforts in evolving its application delivery systems. And, if we’re going to talk about “available expertise,” it’s worth remembering that .NET has been around longer than any of Angular, React or Vue (or even jQuery, for that matter).
But, just to make sure that frontend developers could easily migrate to Blazor, Microsoft designed the Blazor framework using the components-routers-views model that the other major frontend frameworks (Angular, React and Vue) implement. You can see that reflected in the evolving third-party tools market: The toolset that (for example) Telerik UI for Blazor provides to make Blazor developers more productive is almost identical to the toolset that Telerik products provide for other frontend frameworks.
Is It Safe?
But if the question is whether Blazor is “safe” for you to bet your enterprise on, then you can’t think just about the benefits—you must also think about what’s wrong and/or dangerous with the technology: the “problems.”
There is at least one famous “awkwardness” (let’s call it) in Blazor: its initial large download size, something that almost every iteration of Blazor and/or .NET Core has reduced. However, the issue may never go away: It’s possible that Blazor’s initial download will never get down to the size of, for example, of the base React library (not that anyone builds an application with just the base React library).
But it’s also doubtful that size difference matters. Try it out for yourself: Build a Blazor application and download it. Then build an equivalent React app with all the supporting libraries (Redux, React Bootstrap, Axios, etc.) and download it. See if you can actually detect the difference in start-up time (and if you care).
But “safe” also causes you to think about security issues. Unlike existing client-side tools, Blazor started life based on a W3C standard (WebAssembly): Both Blazor and WebAssembly have been implemented using contemporary approaches to security. Blazor probably does a better job of managing authorization claims than any other client-side platform (again, thanks to Blazor’s integration with .NET).
Does that mean Blazor won’t ever have security issues? It probably will. The world is a big, scary place and stuff happens. But, because Blazor is based on a W3C standard and is an integral part of .NET 5, the likelihood that Blazor will have a unique vulnerability is both small and unlikely to be systemic (i.e. if one crops up, it will require a patch, not a rewrite).
It’s not just Microsoft who believe that WebAssembly, the foundation that Blazor builds on, is safe: The Mozilla team is converting components of their Firefox browser to run inside of WebAssembly.
Worrying About the Future
But what about the long term? “Safe” also means something like, “Will we be sorry sometime in the future?” or “Will this decision make me look like a fool/get fired?”
That doesn’t mean that there aren’t other issues to be concerned about with Blazor. For example, in general, Blazor’s performance is fine. However, right now, you should be concerned if you’re going to be displaying tables with hundreds or thousands of rows using Blazor on the client. You can make those problems go away either by using server-side Blazor or adopting Microsoft’s new component virtualization support.
But what if Microsoft hadn’t addressed that UI rendering problem? And what if that’s just the tip of the iceberg? What if there’s some other deficiency in Blazor and a solution is never provided? Alternatively, what if there’s some new “must have” feature that you need to include in your application and Blazor isn’t extended to support/provide it?
We count on two groups to address those problems: First, Microsoft (while Blazor is an open-source project, Microsoft is plainly the primary driver for the technology, like Google is with Angular and Facebook with React); second, an ecosystem that includes tool providers, a pool of expertise on Stack Overflow, and affordable contractors. What if Microsoft loses interest in Blazor (
</cough>) or that ecosystem doesn’t develop as it has with other client-side development tools?
On Microsoft’s side, it’s obvious that the company is making a major bet on Blazor. Not the “bet the company” kind of commitment it made with the original .NET Framework, but Microsoft is still committing a lot of future-oriented resources to Blazor. Microsoft is, for example, just getting started on improving Blazor performance; Microsoft has projects both for integrating Blazor with Xamarin to create smartphone apps and building desktop applications with Blazor. The Uno Platform is already demonstrating that Blazor can be used to deliver a single set of code and associated UI to the Android, iOS, Mac, Windows and web platforms.
Growing an Ecosystem
But what about the ecosystem? If we knew that Blazor would have an effective open-source ecosystem, this post wouldn’t be necessary. Growing an ecosystem depends on developers adopting Blazor… which depends on a viable ecosystem. Like the gingerbread man, an ecosystem can’t run until the technology gets hot, and the technology can’t get hot until the ecosystem is running.
But, having said that…
Let’s sum up: Is Blazor safe to bet your enterprise on?