Is Blazor ready for your next project?
Is Blazor Ready for Prime Time? Truth be told, the question is a bit late. Blazor has been used in mission-critical applications for some time now. But it is worth asking if Blazor is ready for your next project.
What is Blazor?
Blazor is a C# based, single-page app (SPA) framework for building interactive client-side web apps with Microsoft .NET Core. Blazor works in all modern browsers, including mobile browsers. This makes Blazor a significant improvement over older technologies. You can also run Blazor Server server-side if you wish. Blazor maintains a persistent connection to the client via SignalR.
The appeal of Blazor
Blazor is cross-platform. It runs client-side in WebAssembly (WASM) – a compact binary code format that is now a web standard implemented in all major browsers. If you need access to a native runtime environment (if for example you want to access the camera on an iPhone) .NET MAUI and Blazor work well together to give you native runtime access.
Blazor does a good job of minimizing code duplication, and there are few inconsistencies between front and back-end development models to accommodate. One of my favorite things for building lighter applications? Blazor doesn’t require any additional plug-ins for client-side or server-side work.
Why not Blazor?
One word. Silverlight. If you can forgive Microsoft for pulling the rug out on Silverlight, you can keep reading.
Okay, so Silverlight wasn’t that great after all, and pulling the plug was probably an act of mercy for developers. WebAssembly, which hosts Blazor on the client-side, has tons of industry support and won’t be going away anytime soon. But the issue remains, you must trust Microsoft to support Blazor for the foreseeable future. The rumors of .NET8 introducing Blazor United should be a clue of the support Microsoft is putting behind Blazor development. With .NET Core existing independently of any Windows dependencies, it’s my feeling that Blazor will be sticker than Silverlight, AJAX or Web Forms.
Performance issues: There is also a small performance hit with Blazor. Startup and first-launch costs are not negligeable, and they are unlikely to be fixed in future versions of Blazor.
Blazor and server-side execution
What about server-side execution? Because Blazor WebAssembly runs entirely on the client, it doesn’t know when there are server-side changes. Getting notified of server-side changes isn’t hard, you can use a wide variety of protocols to connect, including SignalR, gRPC.
But if you have few users on a fast server and want a lightweight client-side profile, you can run Blazor on the server using Blazor Server. Blazor Server will run every single user interaction on the server and send the changes (if any) back to the client for rendering. Does this sound network and server intensive? Yeah, it kind of does, doesn’t it. Additionally, when running Blazor server-side, it maintains a persistent connection with the client, and client state is stored server-side as well. In the event of a network interruption, Blazor re-connects quickly, and seamlessly once network connectivity is restored. Some developers on Reddit have reported that the ‘quickly’ part can be up to one minute after connectivity is restored. So, unless you have some unavoidable restrictions on the client-side, you will probably be happier running Blazor WebAssembly. Being able to run offline in Blazor WebAssembly is nice too!
Okay, truth be told, all these are rather minor nits compared to Blazor’s advantages, but these issues do keep the anything-but-Microsoft crowd plenty busy criticizing the framework.
So, what’s the bottom line?
Yes, Blazor is ready for business-critical application development. Alternatives that use .NET and C# include WinForms and WebView2. But really, if you’re going to use C# and .NET Core, you’re better off going with Blazor.
How are you planning to use Blazor? Let us know; we’d be happy to lend you a hand! Get in touch with us today.