Blazor full-stack is a trap

Preface

Hello everyone, I'm Xiyuan~

Recently, there's a project that needs to be launched urgently.

Basically, it involves accepting a bunch of client connections to report data, then displaying the data and providing simple control on the interface.

For this kind of scenario, Blazor feels quite suitable, and the urge to tinker is stirring.

So I took out Blazor and started working on it.

Now, .NET 9's Blazor has evolved. Like Next.js, it can run both server and client within the same project. However, it still falls a bit short—the WebAssembly client must be a separate project.

This is also quite understandable. After all, WebAssembly is a separate assembly that needs to be distributed to the browser for execution.

But after working on it for a while, I ended up giving up.

Before I realized I had wasted too much time, I jumped out of the pit in time 🤣

PS: This article represents personal views only, reflecting only the author's own perspective. If you don't like it, please don't criticize.

Causes

There are several aspects to the causes

Ecosystem Issues

The component library for Blazor is somewhat lacking. I tend to use Tailwind CSS component libraries, and Flowbite deserves credit here—not only does it provide support, but it also launched an official Flowbite-Blazor project, though it's still in early development. There's also LumexUI; while it doesn't have many stars, its components are already quite comprehensive and usable.

Looking at this, the ecosystem seems decent—after all, it’s all Tailwind CSS anyway. For any missing components, I can just wrap them myself, and I can also use JSInterop to implement interactivity.

A few years ago, this would indeed be the case.

However, "the times have changed," as I’ve mentioned many times before. We’re now in the age of AI. What does the AI era mean? It means leveraging AI as much as possible for repetitive, non-critical tasks.

In my view, tasks like wrapping common components or doing simple page layouts can be fully delegated to AI generation, followed by personal adjustments—this is how to improve efficiency.

Because of the ecosystem issues, AI support for Blazor is relatively limited. Compared to front-end tech stacks, the AI experience is noticeably lacking.

Stability Issues

Here we're not talking about the framework's stability

but the stability of the documentation and APIs

Blazor is still evolving, and many features and syntax change too rapidly—just like Auth, which keeps shifting. Now when I ask AI to generate code, it sometimes gives me outdated approaches from several major versions back. Isn't that just setting me up? 😂

People used to say frontend updates too fast to keep up

But no matter how the frontend changes, it's still the same things—essentially just JavaScript and CSS

But no matter how the frontend changes, it's still the same things—essentially just JavaScript and CSS.

For frameworks like React, JSX is essentially writing JavaScript.

Tailwind CSS, at its core, is still CSS.

Blazor, however, is different—its ecosystem and syntax evolve directly with the .NET version. Every time .NET releases a major version, the API changes can be significant.

As a result, you might frequently encounter situations like "the documentation and examples use old syntax," "AI-generated code fails to run directly," or "all the answers on StackOverflow are outdated." This uncertainty can greatly reduce development efficiency.

The Illusion of Full-Stack

Blazer's biggest selling point is "full-stack" — you can write C# for both frontend and backend, without dealing with JavaScript, without messing with Node, without npm/yarn/pnpm, and without facing a bunch of frontend engineering configurations. It seems wonderful.

But this is actually a trap.

Because you still have to face the frontend world.

• If you want to create cool interactions, you can't avoid JavaScript in the end;
• If you want to use mature frontend libraries (like charting or rich text editors), you either wait for community wrappers or write JSInterop yourself;
• If you want to optimize build, deployment, SEO, and SSR, Blazor's system simply can't compare to frontend frameworks like Next.js or Nuxt.

In other words, Blazor's "full-stack" is more like "minimizing the frontend," not "completely replacing the frontend." It's like "thinking you won't need to learn JavaScript, when in fact you just don't know when Microsoft will teach you a lesson."

Learning Curve and Team Issues

Another realistic factor is the team.

Front-end engineers are generally familiar with technology stacks like React/Vue/Svelte, whereas Blazor is almost invisible in the front-end community. For personal projects, it might be worth tinkering with; but when it comes to team collaboration, Blazor directly discourages most front-end developers.

Moreover, AI already offers very mature support for mainstream frameworks like React/Vue, from code generation and bug identification to best practice suggestions—it's almost like having "your co-pilot." However, with Blazor, AI assistance is limited, and sometimes it even provides incorrect answers.

This means that while Blazor appears to unify languages, it may actually lock you into an ecosystem where "others can't help."

Performance and Deployment

Let me mention a small pitfall I encountered: WebAssembly.

Blazor WebAssembly essentially brings the .NET runtime into the browser to run and then loads assemblies. The initial load size often starts at tens of MB. Although there's AOT (Ahead-Of-Time) and compression (compression) now, the experience still doesn't match mainstream front-end frameworks.

Blazor Server mode is lightweight, but it requires a persistent connection (SignalR). Once concurrency increases, the server load becomes very high. When moving to a production environment, you'll realize that "small demos are fine, but for real business use, you'd need to think twice."

However, the Server mode was very suitable for my project this time. The number of users wasn't high, so there wouldn't be too much server pressure. The data interaction and persistent connection advantages Blazor offers are quite evident. Unfortunately, I didn't manage to master it, haha 🤣

Summary

Blazor is not a bad framework; it is indeed suitable for certain scenarios, such as:

• Internal tools / management backends;
• Small teams / personal projects;
• Companies heavily reliant on the .NET technology stack.

However, if you want to use "Blazor Full-Stack (Blazor 全栈)" to replace mainstream front-end stacks, or even fantasize about "handling all web projects with just C# by a single person," you are very likely to fall into a pit.

It solves some problems but introduces more potential pitfalls. 🤣

Full-stack development is not a trap—"Blazor Full-Stack" is the trap.

So, my advice is: If you like C#, using Blazor to build some small tools can be quite enjoyable. But for serious production projects, especially those requiring long-term maintenance, team collaboration, and rapid iteration, it's better to stick with React / Vue / Angular and save yourself the trouble.

That said, I remain optimistic about Blazor's potential. Perhaps one day, Blazor Full-Stack will be as powerful as Next.js 💪