I have been anxiously anticipating the release of Blazor – Microsoft’s new .Net component framework that should help free developers from Javascript hell.
Blazor is a new tool for .net developers to allow running C# in the browser, inside web assembly.

What I most like about it is, it is such an clean and simple architecture from the developer’s point of view. Writing a blazor app is very similar to writing your typical MVC/Razor app, that runs on the server. I have always felt that MVC/Razor was ultimately the wrong model – very anti-client/server since all the data/template rendering happens on the server. Until now, there has been no way to run c# in the browser, and have the browser pull the data and assemble the page.
Because MVC/Razor does all the work on the server, JavaScript has been the only option to run in-browser code and pull data popularizing the single page application (SPA) model. From a C# developer’s point of view, Javascript is a terrible language. Its not strongly typed, its interpreted (not compiled), and until recently it has been difficult to debug. Because of all this, frameworks such as Angular, React and Vue have become popular to help hide the mess that can be created by JavaScript. In my opinion, this has in many ways made the problem worse, because additional libraries and packages need to be installed to support frameworks, bloating the code and slowing development time thru trying to orchestrate all this 3rd party code.
Blazor finally replaces all this mess. To do this, they had to wait until all the modern browsers support WebAssembly. Today, the only ‘modern’ browser not supporting it is Internet Explorer 11, and hopefully with the demise of Windows 7 traffic using IE 11 should diminish. There is even an answer if you do need to support older browsers – Blazor Server. Blazor apps can also be written to run on the server, so the codebase can be the same whether you decide to run it on the client or the server. Very elegant.
Using a sample provided by Microsoft, I downloaded, compiled and ran the app in my browser in under 5 minutes. Browsing thru the code, its very readable and understandable. within an hour I was able to customize the demo to call my own API and retrieve data from display it – all without javascript. Contrast that to setting up an Angular app, which could take an hour or two by the time you assembly all the pieces to get the code to run. This article has a great overview of Blazor and the code in the demo. Note that when you first run a Blazor app, it takes all the compiled code (that traditionally runs on the server), and downloads it to the browser. So the first load of the page takes a little time, but once the app is loaded its very fast. One current limitation of Blazor is because the code is running in the browser, inline debugging, setting of breakpoints does not easily work from within Microsoft’s Visual Studio, so this is a step backward in productivity as compared with server development. However, because Blazor consumes class libraries, you can debug class libraries as per usual, prior to implementing them in Blazor. Also, the Blazor team has stated that getting debugging working is a top priority.
Blazor client is still in preview until May of 2020. I think this will be a huge boon to productivity, and I am starting to develop Blazor apps now in preparation for releasing after May. Already it is such an improvement over the JavaScript framework model. As of now, I think the future is bright for client side application development.