When there is something new on the market, we developers want to work with it. There might be several reasons for that, but not always the shortcut decision makers think we favour, which is wanting to try the new shiny thing. Most of the time, we want to work with the new stuff because it makes our lives as developers easier, and an easy life for a developer means that functionalities get developed, products get shipped and the business is happy. But for obscure reasons sometimes this is not understood and when developers propose to use something new it gets refused.
I understand this might not be the case in every country and in every company but given what the internet says it happens often. So now that Blazor is out and the response of the community has been amazing, I imagine that a lot of developers would want to work on a meaningful project that includes Blazor. But the hierarchy at work might not be as eager as us to start a project with Blazor. So how do we convince the decision makers? How do we make our case so we can work with the technology we love without impacting neither delays nor budget? Fortunately, Blazor does most of the work for us!
Now with Blazor, the most amazing thing is that .net developers can now do anything an angular or react developer can, with .net! There’s no need to learn a new language or a way of programming, all you have to do is learn about the architecture of a Blazor project and how to use Blazor like you would learn Entity Framework or Xamarin. The learning curve for a .net developer is quite flat though it still needs effort but in an entire technological ecosystem that is very well familiar with the .net developer.
New tech but established parts
Indeed, Blazor is new, there is no doubt about it. There is a nuance to be made here as while the technology is new, it uses already stable and established regular .net parts. A Blazor page is a Razor page with a code section that contains as the name implies the code to be executed in the page but without any page refresh.
Blazor Web Assembly runtime uses Mono which is also used in Xamarin projects and Blazor Server-Side uses SignalR which has been around for quite a while and is very widely used. All of this is very familiar to the .net developer and it is not something fancy that is under trial. Blazor stayed as an experiment for about two years before being granted the Beta status and being officially included in the .net core roadmap. The reason behind this I believe is that the .net team wanted to see whether there would be enough response from the community to start to think about making Blazor a full part of .net. Given the sheer amount of developers and engineers behind this amazing product, and the fact that it is Open Source, actually guarantee in my opinion the stability and the longevity of Blazor.
Flat learning curve
For any .net developer familiar with Razor Pages and C#, it is very easy to start working on a Blazor Project. All the skills you would need is already mastered by any experienced .net developer. It is just a matter of which method to call where and where to write the code that will be executed in the page.
I may seem to repeat myself here but as Blazor does not really use a lot of new things, there are not a lot to learn to be able to actually deliver production ready web application with the required quality.
Power of attraction
Developers move around companies, chasing after the best project, or the nicest environment, or the best colleagues, or even the best benefits they can find on the job market. So attractivity should not be underestimated here. Simplicity and making the out-of-the-box experience easy are indeed critical to attract and keep the developers.
With Blazor, you can stimulate the natural curiosity and creativity of a .net developer and help her polish her skills. I always wondered how someone could have 5 years of experience in .net with also 5 years as an angular developer, while working for 5 years only. We can all agree that sometimes job descriptions don’t make sense, so imagine that instead of trying to find the best jack-of-all-trades-master-of-none developer, you would gather the best .net developer any manager, product owner or team leader would want. The job description will not aim for the “mouton à six pattes” (french for 6 legged sheep, metaphor for something impossible to find), but would be far more realistic with a big emphasis on .net, C#, something that will be somewhat refreshing on the job market.
Other big players cannot be that wrong.
If your company is working with .net, there is a big chance that developers use Telerik products, like components for WinForms, WebForms or MVC. Telerik is a company that spent years polishing and refining their components for .net developers, so what would that tell us when they started working on a set of components for Blazor while it was merely an experiment? Would they risk investing resources and time in something that they did not see with a big future?
Another point to that is Telerik brought reusable components for Blazor on the market which make it easier to develop awesome web applications using Blazor with even less effort.
It is clearly understandable for companies to not want to be the first to try and use a new technology without any assurances of its future and its stability. Well, Telerik already did that for us. They developed components to make the development of a web application easier, they used their own developers and resources to work on these components so I would choose to trust a big name like Telerik if trusting Microsoft would not be enough.
These arguments might help convince your bosses to use Blazor, or it might not. I tried to gather in one post a few arguments that I think might be appealing to a typical IT management person who has other concerns than us developers, who has to discuss budgets and deadlines with a business that most of the time we know few things of as developers.
I think management has to be convinced instead of fought against. It is in everybody’s interest in a company if the IT department can deliver applications faster, better and more stable. This will cost less money, there will less issues and it uses developers’ time better.
I hope this will help you work with Blazor at work. Don’t hesitate to comment if this was the case, or if it’s not, then feel free to share what was the counter argument.
Happy coding !
This article is an attempt to gather some arguments that might sway your IT management in your favor. I do not guarantee in any way that this will work, nor that this will actually be beneficial for your company.