I've been using Blazor since it was first announced, and it has remained my go-to web UI framework ever since. I was fortunate to use it professionally during my time at Flagship (perk of being the Lead Engineer 😎), where we built production applications with it. Naturally, my site is built using Blazor Server rendering (more on that later), and hopefully, you're enjoying the experience!

My UI Development Journey

My journey into modern UI development started after moving away from my early days in PHP. When I transitioned to .NET and C#, I initially worked with WebForms (what fun that was!) before progressing to WebMVC. WebMVC was a huge leap forward from WebForms, but it didn't take long to realise it lacked interactivity. I started to use PartialViews and good old jQuery to fetch them. Eventually, when I started at Evoke, we began using AngularJS 1.x with TypeScript.

In those early days, I really enjoyed working with JavaScript libraries, but it's such a fast-moving industry with seemingly new "must-use" frameworks appearing every week (or so it feels). I'm not a fan of npm or the whole packaging system for JavaScript libraries either. NuGet and MSBuild aren't perfect by any means, but they feel much easier to manage than the alternatives. So, I was really excited when Blazor was announced, and I'm glad Microsoft has continued to invest in it!

Why I Choose Blazor

Having spent nearly 15 years in .NET, transitioning to Blazor felt like the right fit. The workflow just "clicked" with my brain, and having done so much Razor work in the past, it was a natural move. It also helps immensely that I can write all my business logic in C# (and dip into JavaScript if needed). The ability to share code between the front-end and back-end is helpful but not the primary reason I've chosen it.

Shared Logic Across Platforms

Blazor allows me to share code between the server and the client. This means I can have a single DTO that's used across the application. The advantage here is that during refactoring, the process is end-to-end, reducing the chances of missing something in the UI—a very common issue if the UI has its own model copies!

Robust .NET Ecosystem and Editor Support

Access to the vast .NET ecosystem of libraries, tooling, and strong community support is a huge advantage. Blazor integrates smoothly with services, components, and frameworks I already use and trust. It also has top-tier editor support in Visual Studio, VS Code, and Rider. Having a complete type-safe compiled language with IntelliSense is just amazing.

Performance with WebAssembly

Blazor WebAssembly offers near-native performance by running code directly in the browser. This avoids JavaScript interop overhead in many scenarios, making the user experience smooth and responsive. There is an initial load overhead (as it needs to download the compressed .NET runtime and libraries), but once cached, you won't really notice it.

JavaScript Interoperability

Blazor has full support for working with JavaScript libraries when you need to plug a gap that Blazor can't yet fill. Things like charts and WYSIWYG editors are not fully native to Blazor (mostly due to how it interacts with the browser), so being able to integrate those and still use C# to call them is pretty cool!

Why You Might Want to Choose Blazor

If you're a .NET developer who's worked with MVC or Razor Pages, Blazor is a fantastic choice. It's very easy to pick up, as Blazor components look very similar to cshtml files and Razor syntax. The component model feels familiar, event handling is intuitive, and you can apply your existing knowledge of dependency injection, validation, and service architecture straight away. You've got nothing to lose from trying it out, especially since it slots naturally into the .NET workflow.

If you're new to software development, I'd also suggest giving it a try. One of the biggest advantages of Blazor is that it encourages solid programming principles from day one. Working in a strongly-typed language like C# can teach you good habits around structure, readability, and maintainability. When I started, I found it really valuable to try different languages. Some will just make more sense to you than others, and that's completely normal. Don't just stick with the first one someone recommends, explore, experiment, and find what truly clicks with you.

Microsoft is heavily invested in the future of Blazor and continues to improve it with every .NET release. We've seen major enhancements in performance, new rendering modes, tighter integration with other parts of the .NET ecosystem, and better tooling year over year. Initiatives like Blazor United show that Microsoft is committed to addressing developer feedback, blending the best aspects of server-side and client-side rendering. With every new iteration of .NET, Blazor becomes more powerful, more flexible, and better suited for building modern web applications.

Why You Might Not Want to Choose Blazor

If you're not a .NET developer, Blazor might not be the right choice. There is an overwhelming amount of choice in the JavaScript ecosystem, and if you're already familiar with JavaScript or TypeScript, there's little incentive to learn C# and .NET (unless you want to 😁).

Ecosystem and Maturity

While Blazor has matured rapidly, the JavaScript ecosystem still offers a broader selection of mature libraries and components. If your project heavily depends on specific JavaScript libraries, Blazor may introduce unnecessary complexity. There's also far more educational content, tutorials, books, YouTube videos, etc. for JavaScript and TypeScript.

Additionally, the Blazor job market is smaller compared to the available JavaScript roles. It's growing in popularity, especially with companies heavily invested in C# and WebMVC, but JavaScript still offers greater mobility and broader opportunities. Equally, if you're an employer, you might have difficulty recruiting for Blazor developers.

SEO and Load Times

Blazor WebAssembly apps have slower initial load times compared to traditional server-rendered apps, potentially impacting SEO and user experience. Server-side Blazor can mitigate this, but it introduces trade-offs in scalability and resource usage. Blazor United is addressing this by enabling server rendering that transitions to WebAssembly, but it adds its own complexities and is still in its early days.

Render Modes Complexity

Blazor offers several render modes, interactive (WebAssembly, Server Rendered) and non-interactive static modes. While this flexibility is great, it can make it confusing to choose the right one. Some modes can transition between server and client rendering, adding even more complexity.

Conclusion

For me, choosing Blazor is a no-brainer. I'm a .NET developer who's not the world's best front-end developer 😂. Blazor aligns strongly with my expertise and project needs, enabling me to build interactive applications efficiently. I really enjoy the workflow and find it genuinely fun to work with, which for me is essential.

However, it's crucial to evaluate your specific project requirements and team skill sets to determine if Blazor is the best choice for you. It's growing in popularity (especially within the Microsoft ecosystem), but it will likely never be as dominant as the top JavaScript frameworks. If you work as a Blazor developer, you might enjoy more job security and potentially higher earnings, but you'll have fewer mobility options compared to a JavaScript developer.

I'd recommend giving it a try, especially if you're a .NET developer. I plan to make several blog posts on Blazor over the coming months, so hopefully, you'll start to see some practical benefits when I get those written up. 🙏

Once again, thank you for reading. I hope you found this interesting and insightful!