Blazor desde cero: Capítulo 1 — ¿Qué es Blazor?
Bienvenido al Capítulo 1 de Blazor desde cero. Si te perdiste el post introductorio donde expliqué de qué va esta serie y a quién va dirigida, empieza por allí — es corto.
En este capítulo vamos a responder la pregunta fundamental: ¿qué es Blazor? Parece sencillo, pero la respuesta tiene varias capas, sobre todo porque “Blazor” ha llegado a significar cosas ligeramente distintas con el paso de los años. Al final de este post sabrás qué es Blazor, cómo encaja en el ecosistema .NET, cuáles son los distintos modelos de renderizado y por qué podrías elegirlo — o no — frente a un framework de JavaScript.
Un poco de historia
Blazor empezó como un proyecto experimental de Steve Sanderson en Microsoft alrededor de 2017. La idea era provocadora: ejecutar C# en el navegador usando WebAssembly, eliminando por completo la necesidad de JavaScript. Era una prueba de concepto, y el nombre fue una mezcla deliberada de Blazer y Razor — el motor de plantillas sobre el que Blazor acabaría construyéndose.
El experimento generó suficiente entusiasmo como para que Microsoft lo tomara en serio. Blazor llegó como parte de ASP.NET Core 3.0 en septiembre de 2019, primero como Blazor Server — un modelo que ejecuta tu código C# en el servidor y usa una conexión SignalR en tiempo real para enviar actualizaciones de la UI al navegador. Blazor WebAssembly llegó en mayo de 2020 como parte de ASP.NET Core 3.1, aportando ejecución verdaderamente del lado del cliente al framework.
.NET 6 y 7 refinaron la experiencia del desarrollador. Luego .NET 8, lanzado en noviembre de 2023, replanteó fundamentalmente el modelo de renderizado con lo que Microsoft llamó UI web full-stack. Renderizado estático del lado del servidor, streaming rendering, servidor interactivo, WebAssembly interactivo y un nuevo modo Auto convivían bajo el mismo techo en un único proyecto. .NET 9 construyó sobre esta base y pulió los bordes rugosos.
Ahí estamos hoy.
Qué es Blazor realmente
En esencia, Blazor es un framework de UI basado en componentes para .NET. Construyes tu interfaz a partir de componentes — piezas autocontenidas de C# y marcado HTML que pueden mantener estado, responder a eventos y componerse en estructuras más grandes. Si has trabajado con React o Vue, ese modelo mental te resultará familiar. La diferencia clave es que en lugar de JavaScript, escribes C#.
Los componentes en Blazor se escriben en archivos .razor. Un archivo .razor mezcla marcado HTML con código C# usando la sintaxis Razor que ya puedes conocer de las vistas de ASP.NET MVC. Así es como luce un componente simple:
@page "/counter"
<h1>Contador</h1>
<p>Cuenta actual: @currentCount</p>
<button @onclick="IncrementCount">Haz clic</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
No hay JavaScript a la vista. La directiva @onclick conecta el clic del botón con un método C#. La expresión @currentCount renderiza el valor actual. Cuando cambia el estado, Blazor determina qué actualizar en el DOM.
Ese es el núcleo. Todo lo demás — routing, inyección de dependencias, formularios, llamadas HTTP — se construye sobre este modelo de componentes.
Los modelos de renderizado
Aquí es donde vive mucha confusión, así que seamos precisos. “Blazor” hoy hace referencia a una familia de modos de renderizado, no a un único modelo de despliegue. Entender la diferencia importa porque afecta al rendimiento, los requisitos de infraestructura y lo que tus componentes pueden y no pueden hacer.
SSR estático
El modo más simple. Tus componentes Razor se renderizan en el servidor a HTML y ese HTML se envía al navegador. No hay conexión persistente, no hay WebAssembly y no hay interactividad del lado del cliente por defecto. Es esencialmente lo que hace Razor Pages, pero usando el modelo de componentes.
Úsalo para páginas con mucho contenido, landing pages, cualquier cosa que no necesite interactividad en tiempo real.
Servidor interactivo
Tu código de componente se ejecuta en el servidor. Se establece una conexión WebSocket SignalR entre el navegador y el servidor. Cuando haces clic en un botón o escribes en un input, el evento viaja por el WebSocket al servidor, tu C# se ejecuta, se calcula el diff y las actualizaciones del DOM se envían de vuelta al navegador.
Ventajas: Acceso completo a recursos del servidor (bases de datos, sistema de archivos, secretos). Carga inicial rápida. Tamaño de descarga pequeño. Funciona en navegadores sin soporte de WebAssembly.
Desventajas: Cada interacción del usuario requiere un viaje de ida y vuelta al servidor, lo que añade latencia. Los recursos del servidor escalan con el número de conexiones activas. La app se degrada si la conexión cae.
Úsalo para apps de negocio, herramientas internas, apps donde el acceso a datos del servidor importa más que la capacidad offline.
WebAssembly interactivo
El runtime de .NET se descarga al navegador y tu app se ejecuta completamente en el cliente. Tras la descarga inicial, la app funciona completamente offline y cada interacción es inmediata — sin viajes al servidor para la lógica de UI.
Ventajas: Ejecución verdaderamente del lado del cliente. Funciona offline. Carga del servidor reducida una vez cargada la app.
Desventajas: Descarga inicial mayor (el runtime de .NET + tu app). Primera carga más lenta. Necesitas una API para acceder a datos del servidor.
Úsalo para apps con capacidad offline, herramientas que necesitan capacidad de respuesta inmediata, escenarios donde el procesamiento del servidor no es necesario para la UI.
Modo Auto
Introducido en .NET 8. La app arranca en modo Servidor interactivo (carga inicial rápida, sin esperar que se descargue WebAssembly). Una vez que los archivos de WebAssembly se han descargado en segundo plano, las visitas posteriores cambian automáticamente al modo WebAssembly.
Esto te da la carga inicial rápida del modo Servidor y eventualmente la ejecución completa del lado del cliente de WebAssembly. Es el modelo más complejo de razonar, pero es un punto de partida práctico para muchas apps.
Mezclar modos en la misma app
En .NET 8 y posteriores, no estás limitado a un único modo de renderizado para toda la app. Una landing page puede ser SSR estático; el dashboard autenticado puede ser Servidor interactivo; un widget de visualización de datos puede ser WebAssembly interactivo. El framework gestiona las transiciones.
En esta serie empezaremos con Servidor interactivo porque es el más sencillo de poner en marcha y tiene el modelo mental más directo. Exploraremos los otros modos a medida que avancemos.
Cómo se compara Blazor con los frameworks de JavaScript
Si has construido con React, Angular o Vue, esta es probablemente la comparación que te interesa.
Las similitudes son reales. El modelo de componentes de Blazor es deliberadamente similar al de React. Tienes props (Parámetros en Blazor), estado local (campos en el bloque @code), hooks de ciclo de vida y el mismo patrón de comunicación de datos hacia abajo y eventos hacia arriba. Si conoces React, te sentirás como en casa en pocas horas.
La diferencia clave es el lenguaje. En Blazor escribes C#. Tu lógica de negocio, las reglas de validación y los modelos de datos se pueden compartir entre tu frontend Blazor y tu backend ASP.NET Core. No más duplicar una clase User en TypeScript cuando ya la tienes en C#.
La brecha del ecosistema es real pero se está reduciendo. El ecosistema npm es enorme. El ecosistema NuGet para componentes de UI es más pequeño, aunque ha crecido sustancialmente. Si necesitas una librería de gráficos específica o un widget de drag-and-drop, JavaScript todavía tiene más opciones. Pero para la mayoría de las aplicaciones de negocio, lo disponible en el mundo .NET es más que suficiente.
La interoperabilidad con JavaScript existe cuando la necesitas. Blazor te permite llamar a JavaScript desde C# y a C# desde JavaScript. Para APIs del navegador que todavía no tienen un wrapper .NET, o cuando quieres usar una librería JS existente, el interop está disponible. Añade una capa pero no es doloroso.
La respuesta honesta: si tu equipo son completamente desarrolladores JavaScript construyendo un producto público donde el SEO, el rendimiento y el ecosistema npm son críticos, quédate con JavaScript. Si tu equipo son desarrolladores .NET, si estás construyendo aplicaciones internas o de negocio, o si compartir código entre frontend y backend te importa, Blazor es una opción convincente.
Qué necesitas para seguir la serie
Para el resto de esta serie necesitarás:
- .NET 9 SDK — descárgalo en dot.net
- Un IDE — Visual Studio 2022 (la edición Community es gratuita), VS Code con la extensión C# Dev Kit, o JetBrains Rider
- Comodidad básica con C# — clases, propiedades, interfaces, async/await
Eso es todo. Sin Node, sin npm, sin webpack.
Próxima entrega
En el Capítulo 2 montaremos tu primera app Blazor, recorreremos la estructura del proyecto y nos aseguraremos de que puedes ejecutarla en local. Al final tendrás una app funcionando y una imagen clara de qué hace cada archivo.
Nos vemos allí.