Telerik blogs

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.

There is no doubt that there are things that are potentially… worrisome… about Blazor. To begin with, it’s not JavaScript and JavaScript has been the standard technology for frontend, browser-based development for well over a decade.

But it’s precisely because Blazor isn’t JavaScript that Blazor is an attractive choice. Blazor lets .NET developers use the same toolkit on the browser that they use on the server. This starts with using the same C# entity classes (customers, salesorders) on both the server and the browser, and then goes on to sharing whole .NET libraries.

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>Silverlight</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…

You can see the Blazor ecosystem growing up on GitHub. Another example: Microsoft ensured that it’s easy for Blazor and JavaScript to interoperate so that Blazor applications can, for example, call HTML5 JavaScript APIs. However, the community that already exists around Blazor has generated so many Blazor libraries that wrap JavaScript functionality, developers may never need to explicitly take advantage of the Blazor/JavaScript interoperability.

You can also compare how Blazor UI components by Telerik (only around since 2018, using new WebAssembly technology) is trending against Vue (around since 2014, using good old JavaScript). Blazor already has 25% of the interest that Vue has, according to Google Trends. Or, to put it another way, in terms of trends, Blazor has about the same relationship to Vue that Vue has to React (actually, Blazor is doing better compared to Vue than Vue is doing compared React). You can probably find your own measure (the number of Blazor books on Amazon leaps to mind, for example, or the Blazor toolsets available like Telerik UI for for Blazor). If Microsoft were, for some unknown reason, to lose interest in Blazor, there’s probably already enough of a community around to support Blazor much like the community that exists around Vue.

Let’s sum up: Is Blazor safe to bet your enterprise on?


Peter Vogel
About the Author

Peter Vogel

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter also writes courses and teaches for Learning Tree International.

Related Posts


Comments are disabled in preview mode.