Your Application is not Blazor

Blazor is a wonderful new way to write web-based applications. What is interesting, it is neither for native mobile nor a traditional desktop. Perhaps your application is just a web application, but how much should you risk on a single platform? If you were selling home goods, for instance, you would want your product at multiple retailers instead of just one. Software works the same way--you want multiple avenues to deliver your product. Customers expect you to have a working web, tablet, and native mobile version of your application all at the same time. Your application is not Blazor, and Blazor is not your application. Rather, you can think of Blazor as an advantageous way to present your product to potential customers.

Separating the UI from the application itself gives you one of the most valuable currencies in software development: flexibility. The capability to stand-up an iOS or Android alongside a web application with minimum frustration is extremely valuable. It would be disastrous if an engineering team spent a year developing a self-contained web application only for the marketing team to discover that their customers prefer mobile or desktop. It would take months to rip out all the back-end code and pivot. Separating the various platforms from the start with Blazor eliminates the pitfalls of mono-accessibility. Flexibility is everything.

In one of my first consulting roles, I had a client who overhauled their entire front-end from an "ancient" Silverlight at the time to a passable Durandal web framework. Durandal may have stacked well against the first generation of SPAs, such as AngularJS, but it was clearly outdated when compared to the later Angular and ReactJS. My client had chosen to put most of their application into a solution that contained both front and back-end code. This solution, in turn, communicated to a multiple services in a quasi-SOA style architecture, which caused the front-end and back-end code to be awkwardly married. The only product they could give to their customers was a web application. Worst of all, they were forced to upgrade from Durandal to a modern framework in the next couple of years, reliving this nightmare. Separating the UI from the rest of the application would have minimized many of these issues in the beginning.

A current client of mine is facing the same dilemma with a very similar technology stack. Their entire application is inside a single solution application that contains both the UI and back-end, like a Frankencode amalgamation. They face the same constraints as my other client. They are limited to a web application, and they have a very large solution to maintain. Adding a mobile or desktop application would take months or years to stand-up.

Separating the UI from your application is an insurance policy against the only constant--change! It represents an up-front investment to save future time and headaches. Most companies today are realizing that customers want to engage in different ways, whether traditional web, native mobile, tablet, or desktop. Blazor can fit in to most of those roles. By keeping UI separate from the application, you will reach a greater audience and protect yourself from the pain and cost of adapting.