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.
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.”
So now for the main discussion: “What’s necessary for Blazor to compete with Vue.js, Angular, or React?”
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.
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.