Like many other new technologies, simply using Blazor is no silver bullet for development teams. If you are writing bad code in Angular, React, or Vue, migrating to Blazor will not suddenly solve all your problems. In some cases, it may just make them worse. When choosing to migrate or re-imagine an existing application in Blazor, here are some things to take note of before you commit to a new project:
2) Remembering that the Web is a detail
Blazor, and by extension WebAssembly are very new technologies that are swimming in a sea of equally new technologies. Who could have predicted GraphQL ten years ago? Or WebAssembly. So why with all this predictability are we chaining our web applications to our application code? It is imperative to remember that the web is a detail. Just like how mobile and desktop are both details as well. Save yourself another re-write by separating your application from how it is presented to your customer. By taking the extra effect to put your application code behind a solid API. Blazor can utilize its' built in HttpClient will save your development team countless hours of work when the next great technology comes along.
3) Choosing the correct Blazor app
Blazor is not just a single type of application. It comes as a three pack with different hosting options. You have the option of choosing from a standard WebAssembly app. This is the closest to a traditional SPA application. The app is loaded into the browser and is executed via WebAssembly. A progressive web application where the user my physically download the application into their physical machine which may allow them to run the application with or without an internet connection. And finally, a ASP.NET Core hosted solution where the application is executed server-side and communicates to the browser via SignalR.
4) Not embracing Component-based architecture
Embracing Blazor means you are embracing a component-based architecture that puts composition as a first-class citizen. Blazor is very malleable in that it allows you to approach it in many different ways from an architecture standpoint. This does not give you the green light to attempt to shoehorn what you have done in the past with MVC or Razor Pages with Blazor and expect it to work. Every component should be able to live by itself, and still place nicely with others. Blazor may be state-ful, but components should be state-less when possible. This allows for easier testing and greater re-usability between components. In this aspect, Blazor is related to other component-based frameworks. If you are already comfortable with components in Vue, Angular, or React, you've already know the hardest part of Blazor.
5) Just because you can, does not mean you should