Recently, I came across a fascinating discussion in the .NET community that made me pause and reflect. A developer behind Blazorise asked a simple but profound question: “Why would anyone still choose MVC over Blazor with server-side rendering?” As someone who spends significant time in the .NET ecosystem, I found the responses enlightening and worth exploring.

The question isn’t meant to spark a framework war. Rather, it’s about understanding the real-world considerations that drive technology choices. Let’s dive into what makes this debate more nuanced than it first appears.

The Blazor Promise

Blazor has come a long way since its initial release. With server-side rendering (SSR) working smoothly and the ability to mix static and interactive content, it offers a compelling component-based development experience. For many developers, building in Blazor means:

  • Component reusability that scales across projects
  • Type-safe development with full C# throughout the stack
  • Natural flow without constantly jumping between Razor, ViewModels, and JavaScript
  • Modern patterns that feel more aligned with contemporary web development

These are significant advantages, especially for teams deeply invested in the .NET ecosystem.

The MVC Reality: Why It Persists

But the responses to that question revealed something important: MVC isn’t sticking around just because of inertia. There are legitimate, thoughtful reasons why teams continue to choose it for new projects.

1. Simplicity and Transparency

One recurring theme was: “MVC just works without all the bloated crap on top.” While this might sound dismissive, there’s substance beneath the bluntness. MVC is straightforward:

  • Single HTTP request, single response
  • No persistent connections to manage
  • No multiple rendering modes to understand
  • Clear separation of concerns

As one developer put it, once you move past ViewBag and embrace strongly-typed ViewModels, conventions make your code organized and recognizable.

2. The Performance and Scaling Equation

Different Blazor modes have different performance characteristics:

  • Blazor WebAssembly: Slow initial startup time and nontrivial client CPU requirements
  • Blazor Server: Requires persistent SignalR connections (about 3.5GB for 5,000 concurrent users)
  • Blazor Static SSR: Similar performance to MVC but newer and less proven

For high-traffic public websites where scale matters more than rich interactivity, MVC’s stateless architecture becomes a significant advantage. It’s easier to scale horizontally, resources can be freely expanded or shrunk, and load balancers can route to any backend instance.

3. Team Skills and Familiarity

This might be the most practical consideration. Many teams have:

  • Years of MVC experience
  • Established patterns and practices
  • Proven solutions to common problems
  • Deep institutional knowledge

As one consultant noted: “I can’t think of any project I’ve been involved with lately that would benefit from switching to Blazor.” For established teams, the friction of changing technology stacks has real costs in time, training, and productivity.

4. Microsoft’s Naming Confusion

This complaint came up repeatedly. Microsoft now has:

  • Blazor Server (Interactive)
  • Blazor Server (Static SSR)
  • Blazor WebAssembly
  • Blazor Hybrid

The naming makes it genuinely difficult to search for solutions, understand documentation, and communicate with the team. As one developer quipped: “95% of .NET devs don’t know the difference between these modes.”

5. The Silverlight Trauma

Multiple developers mentioned fear of Microsoft abandoning Blazor like they did Silverlight. While Blazor is fundamentally different (no browser plugins required), the concern is real: “Blazor is still in a low adoption stage where MS could drop it.”

This isn’t irrational paranoia. Microsoft’s history with client-side technologies (WebForms, Silverlight, UWP, WinUI, MAUI) has created legitimate caution.

6. Tooling and Documentation

MVC has been around for over a decade. This means:

  • Extensive Stack Overflow answers
  • Well-understood patterns
  • Better LLM training data (ironically, AI tools work better with MVC)
  • Fewer edge cases and gotchas

Blazor’s relative newness means hitting obscure issues often leads to dead ends. LLMs frequently hallucinate Blazor solutions or suggest inappropriate approaches for different rendering modes.

When Blazor Shines

Despite these challenges, Blazor has clear use cases:

Interactive Applications: If you’re building a SPA or application that requires rich client-side interactivity and component state management, Blazor Server-Side makes sense.

C# Everywhere: Teams that want to avoid JavaScript entirely and leverage C# skills across the full stack find Blazor compelling.

Cross-Platform Components: Blazor components can run in MAUI Hybrid apps with minimal modification, providing real asset leverage for teams building across platforms.

Modern Architecture: For new projects without legacy constraints, Blazor’s component model and type safety offer genuine productivity gains.

The Hybrid Approach: MVC + Modern JavaScript

An interesting middle ground emerged in the discussion: MVC paired with HTMX, AlpineJS, or Vue. This approach gives you:

  • MVC’s simplicity and scalability
  • Modern interactivity where needed
  • Clear separation between server and client logic
  • Familiar patterns for teams skilled in JavaScript

As one developer noted: “Razor Pages + HTMX just works so well and is so easy.”

What About Blazor Static SSR?

Perhaps the most underappreciated option is Blazor Static SSR. It’s essentially Razor Components that render once per request, similar to MVC but with better component support. However, it comes with:

Advantages:

  • No WebAssembly startup time
  • No persistent connections
  • Component reusability
  • Type safety

Challenges:

  • Thread-safety issues (each component renders on its own thread)
  • Pre-rendering quirks requiring null checking
  • Cannot share routes between GET and POST
  • Less mature ecosystem

Making the Choice

So which should you choose? The honest answer: it depends.

Choose MVC when:

  • You need proven scalability for high-traffic sites
  • Your team has deep MVC expertise
  • You’re building primarily static content with occasional interactivity
  • You want maximum control and transparency
  • You’re integrating with existing .NET CMS platforms (Sitecore, Optimizely)

Choose Blazor when:

  • You’re building interactive, component-heavy applications
  • Your team prefers staying in C# throughout the stack
  • You need cross-platform component reuse (web + MAUI)
  • You’re starting fresh without legacy constraints
  • Rich client-side state management is central to your application

Consider the Hybrid when:

  • Your team has strong JavaScript skills
  • You want MVC’s simplicity with modern interactivity
  • You need maximum flexibility
  • You’re working with a design team familiar with JS frameworks

The Bigger Picture

What struck me most about this discussion wasn’t the technical arguments, but the reminder that technology choices are rarely purely technical. They involve:

  • Team capabilities and preferences
  • Business constraints and timelines
  • Risk tolerance and organizational culture
  • Support and maintenance considerations
  • Trust in platform longevity

The fact that MVC continues to thrive alongside Blazor isn’t a failure of either technology. It’s evidence of a healthy ecosystem where different tools serve different needs.

Conclusion

Blazor isn’t “better” than MVC, and MVC isn’t “better” than Blazor. They’re different tools optimized for different scenarios. The best framework is the one that:

  1. Solves your specific problem effectively
  2. Your team can build and maintain confidently
  3. Scales appropriately for your traffic and budget
  4. Fits your organization’s risk profile

As architects and developers, our job isn’t to champion the newest technology. It’s to make informed decisions that serve our users, our teams, and our businesses.

The next time someone asks “Why would anyone still use MVC?”, you’ll have a comprehensive answer. And that answer is: because for many real-world scenarios, it’s still the right choice.

What’s your experience with Blazor vs MVC? I’d love to hear your thoughts and real-world experiences. Drop me a message on Twitter or LinkedIn.