I built the same app twice. Not because the first version broke, but because that was the plan all along.
A while back I started a Sudoku app in Blazor. Not because Blazor was the obvious choice for a Sudoku game, but because I wanted to learn it. My web development roots go back to ASP.NET WebForms, then Silverlight, so the idea of writing C# for the frontend felt familiar and worth exploring. I already knew React well enough, so I figured I'd eventually migrate once I had a handle on what Blazor could and couldn't do.
That's exactly what happened. I built the React version, got it to feature parity with Blazor, and then ran both for a while. Eventually I shut down the Blazor version. This post is about what I learned along the way and why I made that call.
Why I Started with Blazor
The pitch for Blazor is compelling, especially if you come from a .NET background. You write C# instead of JavaScript. Your components look and feel like Razor pages. You get to share models and logic between your frontend and backend without any awkward translation layers. For a developer who's spent years in the .NET ecosystem and dreads the context switch to JavaScript, that sounds great.
I wanted to find out if it lived up to that pitch. And honestly, for the most part, it does. If you're comfortable in C# and you'd rather not think about JavaScript, Blazor is a legitimate path to building a working frontend. That's not a backhanded compliment. For a lot of developers, that trade-off is exactly what they need.
What Blazor Got Right
The development experience in Blazor is solid if you're already in the .NET world. Component authoring feels natural if you've worked with Razor. Dependency injection works the same way it does in your backend services. You can write your game logic, your state management, and your UI all in C#, and it holds together well.
For my Sudoku app, the game logic itself was straightforward to implement. The board state, the validation, the timer — all of it felt comfortable to write. The component model clicked quickly, and I wasn't fighting the framework to do what I wanted.
If I were building an internal tool for a team of backend developers who rarely touch the frontend, Blazor would be a serious option. The learning curve for that audience is genuinely lower than React, and the productivity gains from staying in a familiar language are real.
Where It Started to Show Cracks
Two things gave me trouble.
The first was startup time. Blazor Server has a dependency on a SignalR connection, and Blazor WebAssembly has to download and initialize the .NET runtime in the browser before anything renders. For a game like Sudoku, that cold-start delay is noticeable. Users hit the page and wait. It's not catastrophic, but it's not the snappy experience you get from a JavaScript-based app that renders almost immediately.
The second was PWA support. I wanted to make the Sudoku app installable as a Progressive Web App, and I ran into a wall with Blazor Server. I suspect converting to Blazor WebAssembly would have resolved it, but I'll be honest: I didn't give that path a fair shot. By the time I hit that roadblock, I was already building the React version, and the motivation to dig into a Blazor WebAssembly migration wasn't there.
These aren't necessarily dealbreakers for every project. If your app is internal tooling that nobody needs offline, and your users are on good connections, the startup time is easy to tolerate. But for a public-facing game, it mattered.
Feature Parity in React and What That Revealed
Once I had both versions running with the same feature set, the comparison stopped being theoretical.
The React version loaded faster. Not dramatically so in every case, but consistently. On slower connections or when returning to the app after a while, the difference was obvious. React rendered the board and handed control to the user before Blazor had finished warming up.
The experience of maintaining both versions was also clarifying. Every time I added a feature or fixed a bug, I had to do it twice. Not just twice in terms of typing, but twice in terms of mentally switching between two different component models, two different ways of managing state, and two different build pipelines. It helps with using AI to make the edits, but what you gain in development speed, you lose in code review time. That overhead compounds quickly.
There's also something to be said for the ecosystem. React has been around long enough that almost any UI problem you run into has a well-documented solution, a library, or a Stack Overflow answer. Blazor's ecosystem is smaller and younger, which means you hit the edges of community support more often.
Blazor vs. React: It Really Depends on the Developer
Here's the thing I want to be clear about: this isn't a verdict that React is better than Blazor. It's more nuanced than that.
React is the better choice if you're comfortable with JavaScript or TypeScript. The ecosystem is mature, the performance is excellent, and the tooling is well-established. If your team already works in JavaScript, the productivity advantage of staying there is significant.
Blazor is worth serious consideration if your team comes from ASP.NET or Windows development and genuinely struggles with JavaScript. That's not a rare situation. I know plenty of strong backend developers who are effective in C# and slow and frustrated in JavaScript. For those developers, Blazor lowers the barrier to building a real frontend without asking them to become JavaScript developers first.
The technology isn't the deciding factor. The developer is.
Why I Pulled the Plug on Blazor
Once the React version hit feature parity and I could see the performance difference clearly, the decision wasn't hard. Running two frontends meant double the maintenance work for no user-facing benefit. The React version was faster and had better PWA support. Keeping Blazor alive would have meant continuously splitting my attention between two implementations every time I wanted to make a change.
I marked the Blazor app as deprecated, updated the project page to reflect that the React version is the active one, and moved on.
It was the right call. But I don't regret building the Blazor version first. I learned what I set out to learn, I have a much clearer picture of where Blazor fits and where it doesn't, and the React migration gave me a side-by-side comparison that no amount of reading would have produced.
Wrapping Up
If a developer asked me today whether to use Blazor or React for a new project, my first question would be about the team. Are they comfortable in JavaScript? Go with React. Are they .NET developers who want to stay in C# end to end? Give Blazor a look.
For my Sudoku app, React was the right answer. The startup performance, the PWA support, and the reduced maintenance burden made it clear once I had both versions in hand. But the path through Blazor was worth taking. Sometimes you have to build the thing twice to know which version to keep.