OpinionT2 Light_1200x303

Predicting is hard, especially with Blazor. If you’re trying to decide if Blazor will take off, then don’t look at the technical specs: Look at the ecosystem that is growing up around it. That’s what happened with other successful client-side frameworks like Angular, React, and Vue.js.

If you’re trying to decide if Blazor will take off as a client-side development tool, you should look at the history, not the functionality, of frameworks like React, Vue.js, and Angular.

Twice in the last week I’ve had clients compare Blazor to Microsoft’s previous technology that also supported executing server-side code/libraries in the browser: Silverlight. I think that’s like comparing apples and orangutans. The correct comparison for Blazor is one of the JavaScript client-side frameworks, like React, Angular, or Vue.js. Comparing Blazor to those successful toolsets also has the benefit of highlighting what Blazor needs to succeed.

The critical success factor for Blazor isn’t a technical issue like Ahead of Time compile or reducing the size of the initial download. There are, I bet, multiple clever solutions for those problems (and at least one open-source organization thinks they’ve already solved it). Technical sophistication isn’t what has made Vue.js or Angular or React into successful platforms.

Blazor Isn’t Silverlight

First, let’s discuss the topic “Why Blazor isn’t Silverlight.” Yes, like Blazor, Silverlight was a cross-platform tool that would work with any browser. But Silverlight (like Adobe Flash) was a package separate from the browser. While you could download Silverlight using a browser, it would be more accurate to say that Silverlight ran “in the browser window” rather than “in the browser.” Really, once Silverlight started executing, it didn’t have much to do with the browser.

And, as soon as one major platform (iPad) refused to download Silverlight, Silverlight stopped being a cross-platform tool (its primary reason for existing). Following that, Silverlight followed a similar, though sharper, trajectory to oblivion as Adobe’s Flash. And browser vendors could selectively reject both Flash and Silverlight without compromising their product’s standing as a “good browser.”

Blazor, on the other hand, leverages an HTML5 standard: WebAssembly. Refusing Blazor requires a browser vendor to stop being HTML5-compatible… and not being compatible makes for a bad browser. Blazor leverages native browser functionality in the same way that Vue.js or React or Angular all leverage the browser’s support for JavaScript (and no browser vendor will disable JavaScript). In addition, Blazor isn’t the only WebAssembly-based tool in the universe (here’s a list of over 180 open-source projects that depend on WebAssembly). If a browser vendor turns off WebAssembly, it disables all those projects for the browser’s users.

There are other reasons that a Blazor to Angular/React/Vue.js comparison is apt. Looking at Blazor with its support for components, creating UIs by composition, and routing between components within a single page, it’s obvious that the Blazor team has the same paradigms on their mind as the JavaScript frameworks. Currently, in terms of native functionality, Blazor either matches the functionality of those frameworks or is very close (if, based on your React/Angular/Vue.js experience, you’re about to howl with anger at that claim, bear with me for a minute and remember that I said “native” functionality).

A Sample Ecosystem: Tools and Expertise

So now for the main discussion: “What’s necessary for Blazor to compete with Vue.js, Angular, or React?”

Let me start with a personal experience: I recently finished writing a course on React for Learning Tree International. One of the challenges in writing a React course is dealing with all the stuff that React doesn’t do. React doesn’t have, for example, a built-in mechanism for making Web Service calls like jQuery’s ajax method (you can fall back on JavaScript’s XMLHttpRequest object… but who wants to?). There’s also no support for a centralized store that shares data among all of an application’s components, something that’s essential in any large application.

But, of course, you can do both of those things with React — you just have to pick up the right React add-in. And, for both these examples, there are multiple competing packages… which is what created the problem when I wrote my course: What add-in should I use in the course for managing shared state (vanilla Flux? Redux? Mbot? Relay?) or for making Web Service calls (Axios? isomorphic-fetch? what-wg.fetch?)?

And that’s just the tip of the proverbial iceberg: A quick Google search will give you a page that lists 20 React development tools in a variety of categories. And that’s just the “top 20” tools in one author’s opinion — there are far more.

But, for all of the grief this richness gives me when I’m wearing my course author hat, it’s a boon to me when I put on my developer hat: I can pick the tool that best meets the need of my particular application or client. The ecosystem that exists around React is what makes React (and the other successful client-side platforms) a great development choice.

But tools are just part of a technology’s ecosystem. As someone who firmly believes that the real definition of “programming” is “Googling Stack Overflow,” the other critical part of an ecosystem is available expertise.

Continuing with React as my example, Amazon lists (literally) hundreds of titles devoted to React, ranging from soup-to-nuts coverage of the tool, to guides on best practices, to titles that drill down into specific React add-ins. Online, there is a universe of blogs (here are 10 just for starters). And coming up with a React-related question that isn’t already answered on Stack Overflow is very hard to do (heaven knows I’ve tried). You’ll get the same results with Vue.js or Angular.

Expertise doesn’t end with gurus, however. Implementing applications using any technology requires people. As the ex-head of an IT department, I’m only interested in a technology when there are lots of consultants, contractors, and potential new hires available at a cost I can afford. I’d rather use a technology that has lots of reasonably-priced people available than a technically “superior” technology that requires high-priced ninjas who, probably, aren’t available to me anyway.

The Blazor Ecosystem

As a tool that’s really only a year old, obviously Blazor can’t be expected to have the kind of resources that either Vue.js or React (both six years old) or Angular have (three years in its current version, ten years if you count its previous existence as AngularJS). But, because Blazor leverages .NET Core and the C# language, much of the expertise required to use Blazor is already in place: If you know .NET Core, you know much of what matters in Blazor.

I’d also suggest that much of the conceptual knowledge required by Blazor (composition using components, routing inside a page) is already known by React, Vue.js, and Angular developers: The details change but the song remains the same. A .NET developer who works with any of these client-side frameworks already has much of the necessary expertise to build Blazor applications.

Which means that what Blazor is currently missing is that tools ecosystem.

Here, as with any new technology, Blazor can suffer from the “gingerbread man problem”: He can’t run until he gets hot and he can’t get hot until he runs. A tools ecosystem grows up where there are lots of developers extending the core platform but “lots of developers” are only attracted to platforms where there’s a rich ecosystem.

Still, it happens: In terms of developer interest/awareness/satisfaction both Vue.js and React have, in the last five years, supplanted Angular as the top-rated tools. Presumably, the same thing could happen with Blazor.

And some of that is already happening. Vendors (like Progress with Telerik) are providing suites of UI controls comparable to the suites available to other platforms. Initially, much of the open-source developer community has focused on providing Blazor with functionality that is native to the JavaScript frameworks (i.e. access to the HTML5 APIs, like geolocation). But that’s changing as the community adds new functionality (there’s already a Blazor package that provides Redux-equivalent functionality).

So the real question is, “How is the tools ecosystem for Blazor growing?” Keep your eye on that growth. If that ecosystem of tools grows in the same way that it has for Angular, React, or Vue.js, then you should expect to see Blazor muscle its way into that crowd. And if it doesn’t… well, Blazor is still interesting technology.

And not like Silverlight. At all.

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.