CleenUI as a Blazor alternative — same .NET 8 backend, React frontend instead of Blazor.
Blazor is Microsoft's framework for writing client-side and server-side web UI in C#. It targets .NET teams who want to stay in one language end-to-end. CleenUI solves the same problem differently — same .NET 8 + ASP.NET Core + Azure SQL backend (Dapper + ADO.NET, no EF), but a React 18 frontend instead of Blazor. The trade-off is language uniformity (Blazor's strength) vs. ecosystem depth (React's strength).
| Concern | CleenUI | Blazor |
|---|---|---|
| Frontend tech | React 18 + TypeScript-ready JSX | C# (Blazor WebAssembly or Blazor Server) |
| Backend tech | .NET 8 (same) | .NET 8 (same) |
| Component ecosystem | Native CleenUI — 61 components built specifically for the codebase | MudBlazor, Telerik Blazor, Syncfusion, etc. |
| Bundle size | Standard React bundle (~150-200 KB initial gzipped) | Blazor WASM ships .NET runtime (~1.5-3 MB initial) |
| Server-side option | Standard SSR (optional) — codebase ships as SPA | Blazor Server (websocket-based, low-latency) |
| Reactivity model | React hooks + composition | C# component model with one-way binding |
| Distribution | Licensed source code (one-time license) | Open-source .NET |
Teams replace Blazor with CleenUI when they want React's ecosystem depth (component libraries, hiring pool, npm ecosystem), when bundle size matters (public-facing apps where Blazor WASM's payload is prohibitive), or when they're building a product they'll hire React engineers for at scale. Teams stay on Blazor when end-to-end C# is a non-negotiable requirement.
The backend stays familiar — same .NET 8 + ASP.NET Core patterns you're used to (data access is Dapper + ADO.NET + stored procedures rather than EF, which is closer to how high-perf .NET shops actually run). The frontend learning curve (React + hooks) is moderate for a C# team; CleenUI's component library is opinionated enough to absorb most of the early uncertainty.