Blazor es un framework web de .NET para crear interfaces interactivas con C#, HTML y componentes Razor.
Su principal atractivo es que permite usar C# y compartir código .NET entre distintas partes de la aplicación. JavaScript no desaparece (el navegador sigue teniendo sus propias API), pero deja de ser obligatorio para buena parte de la lógica de la interfaz.
Blazor no transpila tu código C# a JavaScript.
Blazor ejecuta código .NET real, ya sea en el servidor o directamente en el navegador mediante WebAssembly.
Por qué usar Blazor
La principal ventaja es la productividad. Si ya conoces el ecosistema .NET, no tienes que cambiar de contexto mental para escribir el frontend.
También hay razones técnicas de peso:
- Código compartido: Puedes usar las mismas clases (DTOs, validaciones, modelos) en el cliente y en el servidor. Adiós a duplicar la definición de tus objetos en TypeScript.
- Ecosistema: Tienes acceso a las bibliotecas de NuGet estándar de .NET.
- Herramientas y tipado: Disfrutas del tipado estático de C#, la inyección de dependencias y las herramientas de depuración del ecosistema .NET.
¿Cómo funciona por dentro?
Blazor se basa en una arquitectura de componentes. Una aplicación Blazor no es más que un árbol de componentes que se renderizan para formar la interfaz de usuario.
Estos componentes se escriben en archivos con extensión .razor, que mezclan HTML estándar con sintaxis C#.
<h3>Contador: @currentCount</h3>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}Internamente, Blazor mantiene una representación en memoria del DOM (un “Render Tree”). Cuando el estado cambia (por ejemplo, al hacer click), Blazor calcula la diferencia (diff) y actualiza solo las partes necesarias del DOM real.
Modelos de renderizado (.NET 8+)
La evolución de la tecnología añade un matiz interesante que suele crear confusión.
Hasta .NET 7, tenías que elegir tu “bando” al crear el proyecto: ¿Blazor Server o Blazor WebAssembly? Eran proyectos distintos.
Desde .NET 8, Microsoft unificó todo bajo el concepto de Blazor Web App. Ahora, “Server” y “WebAssembly” ya no son solo tipos de proyecto separados, sino modos de renderizado que puedes elegir componente a componente.
Vamos a ver las opciones que tenemos disponibles hoy en día.
En este modo, la aplicación se ejecuta completamente en el servidor.
El navegador actúa como una “terminal tonta”. Se establece una conexión SignalR (WebSockets) entre el cliente y el servidor. Cuando haces clic en un botón, el evento viaja al servidor, se procesa el C#, y el servidor envía de vuelta los cambios exactos que deben pintarse en el HTML.
- Ventajas: La carga inicial es rapidísima (no hay que descargar librerías .NET). Tienes acceso directo a base de datos y servicios del servidor.
- Desventajas: Necesitas conexión permanente. Si se cae internet, la app deja de responder. La latencia puede ser un problema si el servidor está lejos. Consume mucha memoria en el servidor por cada usuario conectado.
Aquí la aplicación (las DLLs de tu código y una versión reducida del runtime de .NET) se descarga al navegador y se ejecuta allí usando WebAssembly.
- Ventajas: La ejecución y el renderizado interactivo recaen en el cliente, por lo que no necesita un circuito permanente con el servidor.
- Desventajas: La carga inicial es más lenta (hay que descargar el runtime de .NET, aunque se cachea).
Ejecutar la interfaz con WebAssembly no convierte por sí solo la aplicación en offline. Para ello necesitas una PWA, almacenar los recursos necesarios y diseñar también el acceso a los datos sin conexión.
Esta es la opción base en las plantillas modernas. La página se renderiza en el servidor y se envía como HTML puro al navegador.
No hay WebSockets ni WebAssembly. Es como funcionaban las webs antiguas (o MVC/Razor Pages), pero usando la sintaxis de componentes de Blazor. Es ideal para páginas que no requieren interacción compleja, como blogs o landing pages, y es perfecto para SEO.
El modo Auto es una de las novedades más interesantes de .NET 8+. Combina lo mejor de los dos mundos.
- Cuando el usuario entra por primera vez, el componente usa Interactive Server.
- En segundo plano, el navegador descarga los ficheros de WebAssembly.
- Cuando el paquete ya está disponible, las visitas posteriores pueden usar Interactive WebAssembly.
El modo Auto evita esperar a que WebAssembly termine de descargarse en la primera visita. El modo elegido se mantiene mientras el componente permanece en la página; no migra su estado en caliente del servidor al navegador.
Comparativa de los modos interactivos
Para tenerlo claro de un vistazo, podemos comparar los modos así:
| Característica | Server | WebAssembly | Auto |
|---|---|---|---|
| Lugar de ejecución | Servidor | Navegador | Ambos |
| Carga inicial | Rápida | Mayor (descarga el runtime) | Rápida en la primera visita |
| Conexión permanente | Sí (SignalR) | No | Solo mientras usa Server |
| Acceso a recursos | Servidor completo | Sandbox del navegador | Ambos |
¿Cuál debo elegir?
Como punto de partida, puedes seguir este criterio:
- Empieza creando una Blazor Web App.
- Usa Static Server Rendering (SSR) para las páginas públicas, formularios simples y contenido estático (Login, Home, About).
- Usa Interactive Auto cuando te interese una primera respuesta rápida y el componente pueda ejecutarse también en el proyecto cliente.
La elección final depende de la latencia, la carga del servidor, el tamaño de descarga y el acceso que necesite el componente a recursos del servidor.
En el próximo artículo, nos arremangaremos para preparar nuestro entorno y crear nuestro primer proyecto para diseccionar su estructura.
