Lic. Carlos Enrique Loria Beeche

Introducción: casi cincuenta años viendo cambiar la programación

Empecé a programar en 1976, cuando la informática era un mundo muy diferente. Era la época de las calculadoras programables, las tarjetas perforadas y los listados impresos. Un error tipográfico podía significar esperar horas para descubrir, en un fajo de papel, que algo tan sencillo como un carácter incorrecto había impedido ejecutar un programa.

Desde entonces he tenido la oportunidad de atravesar varias generaciones de tecnología. Programé en COBOL y Pascal, escribí módulos en lenguaje ensamblador para DOS, desarrollé sistemas distribuidos sobre redes Novell utilizando C++ y viví la transformación que convirtió las computadoras personales en verdaderas plataformas empresariales.

Cuando Microsoft puso en circulación las primeras versiones Alpha de C# y .NET, antes incluso de que existiera una Beta pública, tuve la fortuna de comenzar a trabajar con aquella plataforma. Esa relación temprana con C# terminó llevándome a ser reconocido como Microsoft MVP en C# durante 2001, 2002 y 2003, en una época en la que SQL Server 2000, Windows y .NET comenzaban a redefinir el desarrollo empresarial.

He trabajado como desarrollador independiente desde 1985 y he acumulado más de 120 meses efectivos de docencia universitaria. Menciono estos datos no por nostalgia, sino porque haber vivido varias revoluciones tecnológicas concede una perspectiva particular: las tecnologías cambian con enorme rapidez, pero los problemas fundamentales de la ingeniería de software cambian mucho menos.

Hoy, en 2026, me enfrento nuevamente a una transición importante: modernizar un amplio ecosistema de aplicaciones Windows Forms y llevar progresivamente sus funciones al entorno web.

Y aparece entonces una pregunta que no es meramente tecnológica:

¿Debemos seguir la enorme inercia del mercado y utilizar React, o ha llegado el momento de considerar seriamente Blazor sobre .NET 10 como plataforma principal para nuevas aplicaciones empresariales?

Después de analizar ambas opciones, mi conclusión es cada vez más clara: para quienes ya tenemos una inversión considerable en C#, .NET y lógica empresarial acumulada durante años, Blazor ha dejado de ser una curiosidad tecnológica y se ha convertido en una alternativa arquitectónica muy seria.

No porque React haya dejado de ser dominante. Precisamente porque no lo ha hecho.

La hegemonía de React es real

Conviene empezar reconociendo los datos.

React sigue teniendo una posición extraordinariamente fuerte en el desarrollo web. En la encuesta de desarrolladores de Stack Overflow de 2025, React aparecía utilizado por el 44,7 % de todos los participantes y por el 46,9 % de los desarrolladores profesionales. Blazor alcanzaba aproximadamente 7 % y 7,6 %, respectivamente.

Por tanto, sostener que Blazor está desplazando a React sería difícil de defender.

Pero esa tampoco es la pregunta correcta.

Una decisión arquitectónica empresarial no debería reducirse a escoger la tecnología con mayor porcentaje de utilización. De ser así, jamás aparecerían alternativas nuevas y todas las organizaciones terminarían utilizando exactamente la misma plataforma.

La pregunta importante es otra:

¿Cuál tecnología reduce mejor el costo total de construir, mantener y evolucionar mi software durante los próximos diez años?

Ahí cambia considerablemente la discusión.

React —que estrictamente es una biblioteca de interfaz y normalmente forma parte de un stack mayor— tiene ventajas enormes: un ecosistema gigantesco, incontables bibliotecas, abundancia de profesionales, excelentes herramientas y años de experiencia acumulada en aplicaciones de prácticamente cualquier dimensión.

No tendría sentido negarlo.

Pero cuando el backend empresarial está escrito en C#, React introduce inevitablemente una frontera tecnológica. Aparecen TypeScript y JavaScript en el cliente, C# en el servidor, herramientas como npm en un lado y NuGet en el otro, modelos que deben mantenerse sincronizados y contratos entre frontend y backend que necesitan ser administrados.

Nada de eso convierte a React en una mala arquitectura. Existen magníficas soluciones para manejarlo: OpenAPI, generación automática de clientes TypeScript, esquemas compartidos y buenas estrategias de integración.

Pero esa separación tiene un costo.

Y para una organización profundamente instalada en .NET, Blazor plantea una pregunta muy interesante: ¿es indispensable asumir ese costo?

La IA no eliminó la ingeniería de software

Esta discusión se vuelve todavía más interesante por la llegada de la inteligencia artificial generativa.

En los últimos años se popularizó el término “vibe coding” para describir un estilo de desarrollo en el que se explica a un modelo lo que se desea, se acepta gran parte del código generado y se avanza rápidamente sin comprender necesariamente cada detalle de su implementación.

La inteligencia artificial ya es una herramienta importantísima para desarrollar software. Negarlo sería tan absurdo como haber rechazado en su momento los compiladores, IntelliSense o los entornos integrados de desarrollo.

Pero utilizar IA no significa que la ingeniería haya dejado de ser necesaria.

Los propios desarrolladores lo están descubriendo. En la encuesta de Stack Overflow de 2025, 84 % utilizaba o planeaba utilizar herramientas de IA, pero solamente 33 % manifestaba confiar en su exactitud, frente a 46 % que expresaba desconfianza. Más revelador todavía: 66 % señalaba como una de sus principales frustraciones recibir soluciones de IA “casi correctas, pero no del todo”, mientras que 45 % encontraba que depurar código generado por IA podía requerir más tiempo. Además, la gran mayoría afirmó no practicar vibe coding en su trabajo profesional.

Esto coincide con algo que décadas de programación enseñan rápidamente: producir código y producir software son dos actividades distintas.

La IA puede generar una clase, un endpoint, una consulta SQL o incluso una aplicación completa. Pero alguien debe comprender las consecuencias de las decisiones arquitectónicas, revisar seguridad, concurrencia, transacciones, persistencia, rendimiento y mantenibilidad.

Paradójicamente, cuanto más código pueda producir una IA, más importante se vuelve disponer de una arquitectura coherente que limite dónde y cómo puede producirlo.

Aquí encuentro una ventaja considerable en .NET.

Un sistema fuertemente tipado, con contratos claros, compilación estricta, pruebas y una arquitectura bien definida proporciona a los agentes de IA un espacio de trabajo mucho menos ambiguo. La IA no sustituye al ingeniero; se convierte en una herramienta extraordinariamente poderosa cuando trabaja dentro de una ingeniería sólida.

.NET 10 cambia el contexto

.NET 10 fue publicado el 11 de noviembre de 2025 como versión LTS. Microsoft mantiene las versiones LTS durante tres años, y .NET 10 tiene soporte previsto hasta el 14 de noviembre de 2028.

Eso importa especialmente en aplicaciones empresariales.

Quienes mantenemos sistemas durante diez, quince o veinte años sabemos que el costo verdadero del software rara vez está en escribir su primera versión. Está en mantenerlo cuando cambian los procesos, las bases de datos, los sistemas operativos, las regulaciones y las personas responsables del código.

Pero la razón para considerar Blazor no es únicamente disponer de una versión LTS.

El cambio más significativo está en el modelo que Microsoft denomina Blazor Web App.

Hoy una aplicación Blazor no obliga a escoger rígidamente entre “Blazor Server” y “Blazor WebAssembly”. Una misma aplicación puede utilizar renderizado estático en servidor, Interactive Server, Interactive WebAssembly o Interactive Auto, incluso aplicando diferentes estrategias a distintos componentes.

Eso cambia radicalmente la arquitectura.

Una pantalla administrativa sencilla puede renderizarse en el servidor. Un componente que necesita gran interactividad puede ejecutarse mediante WebAssembly. Y el modo automático puede comenzar utilizando interactividad desde el servidor mientras se descarga el runtime WebAssembly para visitas posteriores.

En otras palabras, ya no estamos obligados a tomar una única decisión de renderizado para toda la aplicación.

Podemos tomarla componente por componente.

El verdadero atractivo: C# de extremo a extremo

Para mí, esta es probablemente la característica más importante.

Con Blazor puedo utilizar C# tanto en el servidor como en los componentes interactivos del cliente.

Eso no significa que HTML, CSS y JavaScript desaparezcan. Seguimos construyendo aplicaciones web y debemos conocer la plataforma web. Además, existen circunstancias en las que la interoperabilidad con JavaScript continúa siendo necesaria.

Pero desaparece buena parte del cambio permanente de contexto entre dos ecosistemas de programación.

DTO, enumeraciones, validadores y determinados contratos pueden compartirse entre proyectos. Las reglas que realmente pertenecen al dominio pueden permanecer en bibliotecas .NET en lugar de ser implementadas nuevamente en JavaScript.

Y esto tiene una consecuencia adicional que considero particularmente valiosa: el compilador vuelve a participar en una parte mucho mayor del sistema.

Si cambio un contrato, quiero descubrir qué rompí cuando compilo, no tres semanas después cuando determinado usuario entra en una pantalla poco utilizada.

Ese tipo de seguridad tiene un enorme valor económico.

WebAssembly: potencia, pero sin exageraciones

Otro argumento frecuente a favor de Blazor es WebAssembly, pero aquí conviene evitar afirmaciones simplistas.

Blazor WebAssembly puede utilizar compilación Ahead-of-Time (AOT) para convertir código .NET directamente en WebAssembly. Esto puede producir mejoras importantes de rendimiento en aplicaciones con procesamiento intensivo de CPU.

Sin embargo, AOT no es gratuito ni es necesariamente la mejor opción para todas las aplicaciones.

Sin AOT, Blazor utiliza ejecución de IL mediante el runtime WebAssembly. Al habilitar AOT se mejora la velocidad de ejecución, pero también crece el tamaño descargado. La propia documentación de Microsoft advierte que una aplicación AOT suele resultar considerablemente mayor —frecuentemente alrededor del doble— que su equivalente basado en IL.

Es, por tanto, un intercambio clásico de ingeniería: tiempo de descarga frente a rendimiento de ejecución.

Para una aplicación CRUD empresarial tradicional probablemente no escogería AOT únicamente porque existe. Para procesamiento intensivo, cálculos locales, manipulación de datos o determinadas aplicaciones desconectadas, podría ser extraordinariamente útil.

La característica importante no es “Blazor es más rápido porque tiene AOT”.

La característica importante es tener esa opción cuando el problema lo justifica.

C# 14: pequeñas mejoras que juntas importan

.NET 10 llega acompañado por C# 14, que incorpora varias mejoras interesantes.

El nuevo identificador contextual field, por ejemplo, permite escribir propiedades con lógica en sus accesores utilizando el campo de respaldo generado por el compilador, evitando declarar manualmente variables privadas. C# 14 incorpora además asignaciones mediante acceso condicional nulo —como cliente?.Orden = ObtenerOrden()— y nuevos extension members, capaces de expresar no solamente métodos sino también propiedades y otros miembros de extensión.

Ninguna de esas características justificaría por sí sola migrar una arquitectura a Blazor.

Pero juntas representan algo más importante: C# continúa evolucionando como un lenguaje moderno sin abandonar la compatibilidad, la seguridad de tipos y la expresividad que lo han convertido en una plataforma empresarial madura.

Para quienes llevamos décadas trabajando con el lenguaje, no estamos abandonando nuestra inversión intelectual para entrar al navegador. Estamos llevando esa inversión al navegador.

Observabilidad: cuando Blazor deja de ser un experimento

Otro de los avances que considero especialmente relevantes es la observabilidad.

.NET 10 permite integrar métricas y trazas de Blazor mediante OpenTelemetry. Se pueden medir, entre otras cosas, la duración del procesamiento de eventos, el tiempo empleado actualizando parámetros, el tamaño y duración de los lotes de renderizado y, en aplicaciones con interactividad en servidor, la cantidad de circuitos activos y conectados.

Esto puede parecer una característica secundaria hasta que una aplicación entra en producción.

Entonces aparecen las preguntas reales:

¿Por qué esta pantalla tarda más que ayer? ¿Cuántos circuitos estamos manteniendo en memoria? ¿Qué componente está provocando renderizados costosos? ¿Qué evento precedió a una excepción?

Pasar de “parece que funciona” a poder responder esas preguntas mediante telemetría es precisamente lo que diferencia una plataforma interesante de una plataforma preparada para producción empresarial.

Server-Sent Events y aplicaciones con IA

ASP.NET Core 10 añadió también soporte directo para Server-Sent Events (SSE) mediante TypedResults.ServerSentEvents. SSE permite que el servidor mantenga un flujo HTTP hacia el navegador y entregue eventos progresivamente.

Para aplicaciones que incorporan inteligencia artificial esto resulta especialmente conveniente.

Un modelo generativo puede producir una respuesta token a token mientras ASP.NET la transmite progresivamente al navegador, sin esperar a que concluya toda la generación.

SSE no sustituye a SignalR ni a WebSockets cuando se necesita comunicación bidireccional en tiempo real. Pero para streaming unidireccional —incluidas muchas interfaces de IA— ofrece una solución considerablemente más sencilla.

Y alrededor de todo ello existe además Aspire, que en 2026 ya se encuentra en la rama 13.x; Aspire 13.4 amplió sus capacidades de orquestación, despliegue, telemetría y aplicaciones políglotas.

De nuevo aparece el mismo patrón: una plataforma que permite mantener el núcleo empresarial en .NET sin impedir interactuar con Python, JavaScript, contenedores, servicios de IA u otros componentes cuando el problema lo exige.

Migrar WinForms no significa traducir formularios

Este punto me parece fundamental.

Migrar una aplicación WinForms a Blazor no consiste en convertir cada Form en un archivo .razor.

La interfaz debe ser replanteada.

La web tiene otro modelo de navegación, otro ciclo de vida, otras expectativas del usuario y otra forma de manejar estado y concurrencia.

La inversión que realmente podemos recuperar está en otro sitio: lógica empresarial, acceso a datos, modelos, reglas de cálculo, validaciones, procesos y conocimiento del dominio.

Microsoft mantiene WinForms activamente en .NET 10 y dispone incluso de herramientas de modernización para migrar aplicaciones antiguas desde .NET Framework. También ha mostrado estrategias concretas para evolucionar desde WinForms hacia Blazor.

Eso permite una estrategia mucho más prudente que una reescritura total.

Podemos separar primero las reglas de negocio de la interfaz, llevar bibliotecas reutilizables a .NET moderno, crear servicios y APIs y sustituir gradualmente determinadas funciones por aplicaciones web.

Incluso aplicaciones ASP.NET Core existentes basadas en MVC o Razor Pages pueden incorporar componentes Razor interactivos progresivamente. No es obligatorio reemplazar todo el sistema de una sola vez.

Después de muchos años desarrollando sistemas empresariales, esta capacidad de modernización incremental me parece mucho más importante que cualquier demostración espectacular de tecnología.

Blazor no tiene que ser monedita de oro

Hay un dicho que conocemos bien: nadie es monedita de oro para caerle bien a todo el mundo. Con las tecnologías ocurre exactamente lo mismo.

Blazor no necesita ser la mejor opción para todos los desarrolladores, todas las empresas ni todos los proyectos para convertirse en una excelente decisión arquitectónica.

React posee un ecosistema frontend muchísimo mayor, una comunidad enorme, miles de componentes disponibles y una oferta considerable de profesionales con experiencia. Si una organización cuenta con un equipo especializado en TypeScript, si su producto depende intensivamente del ecosistema JavaScript o si está construyendo una solución cuyo centro de gravedad está claramente en el frontend, React puede ser perfectamente la opción más conveniente.

Reconocerlo no debilita el argumento a favor de Blazor. Al contrario: permite identificar con mayor claridad dónde están sus verdaderas fortalezas.

Blazor WebAssembly, por ejemplo, debe descargar inicialmente el runtime y los ensamblados necesarios para ejecutar .NET en el navegador. Esa característica puede resultar irrelevante en una aplicación empresarial utilizada regularmente, pero merece consideración en aplicaciones públicas donde el tiempo de primera carga es crítico.

El modelo Interactive Server presenta otro intercambio interesante. Permite interfaces muy ágiles con una descarga inicial pequeña, pero mantiene un circuito entre cliente y servidor y, por tanto, la latencia, la conectividad y los recursos del servidor pasan a formar parte de la ecuación arquitectónica.

También debemos aceptar que el navegador continúa siendo territorio natural de JavaScript. Blazor reduce enormemente nuestra dependencia de él, pero no pretende hacerlo desaparecer. Determinadas bibliotecas, APIs del navegador o componentes especializados pueden requerir interoperabilidad con JavaScript, y eso no constituye una derrota del modelo: es simplemente utilizar cada tecnología allí donde aporta mayor valor.

Finalmente, el mercado laboral de Blazor sigue siendo considerablemente menor que el de React. Para una empresa que necesita contratar rápidamente grandes equipos de frontend, este factor puede pesar mucho más que para una organización que ya dispone de desarrolladores experimentados en C# y .NET.

Y precisamente ahí aparece el punto central de este ensayo.

Las mismas características pueden representar una debilidad en un contexto y una fortaleza extraordinaria en otro.

Si comienzo desde cero con un equipo especializado en JavaScript, React tiene argumentos formidables.

Pero si parto de años de experiencia en C#, bibliotecas .NET, modelos de dominio, reglas empresariales, SQL Server y desarrolladores que conocen profundamente ese ecosistema, la ecuación cambia.

Blazor no necesita ganar una elección universal contra React.

Necesita resolver bien mi problema.

Y esa quizás sea una de las lecciones que deja la experiencia en ingeniería de software: no existe una tecnología perfecta; existen tecnologías adecuadas o inadecuadas para un determinado contexto.

La buena arquitectura no consiste en escoger la herramienta más popular.

Consiste en comprender suficientemente bien nuestras fortalezas, nuestras restricciones y nuestros objetivos para escoger la herramienta que mejor nos permita construir y mantener el software que realmente necesitamos.

Los cambios que debemos vigilar al adoptar .NET 10

Actualizar una plataforma tampoco significa simplemente modificar el TargetFramework.

C# 14 introdujo conversiones implícitas adicionales para Span<T> y ReadOnlySpan<T>, y eso puede modificar la resolución de determinadas sobrecargas. Microsoft documenta específicamente escenarios donde código que antes seleccionaba métodos de LINQ puede terminar enlazándose con implementaciones basadas en Span, cambiando incluso el comportamiento esperado.

Es exactamente el tipo de cambio que merece una batería seria de pruebas durante una migración.

También debemos distinguir cuidadosamente los cambios de OpenAPI. ASP.NET Core 10 añadió soporte nativo para OpenAPI 3.1 y JSON Schema 2020-12, y WithOpenApi quedó obsoleto.

Esto puede requerir ajustes en aplicaciones existentes, pero no debe confundirse con la actualización de Microsoft.OpenApi a la rama 3.x, que constituye un cambio mayor documentado para ASP.NET Core 11, no para .NET 10.

Estos detalles son importantes porque las migraciones exitosas no se construyen con entusiasmo; se construyen con inventarios, pruebas, telemetría y capacidad de retroceder cuando algo falla.

Entonces, ¿por qué elegiría Blazor?

Después de casi cincuenta años viendo aparecer tecnologías que prometían cambiarlo todo, mi criterio se ha vuelto relativamente sencillo.

No quiero la tecnología que produzca la demostración más espectacular.

Quiero la que me permita entregar software mantenible durante muchos años.

Si estuviera creando una compañía completamente orientada al frontend, rodeado de especialistas JavaScript y partiendo de cero, React estaría indudablemente entre mis primeras opciones.

Pero esa no es mi realidad.

Mi punto de partida es un patrimonio tecnológico construido alrededor de C#, .NET, SQL Server y décadas de lógica empresarial.

En ese contexto, Blazor cambia la ecuación.

Me permite mantener C# como lenguaje predominante, compartir contratos y determinadas reglas, utilizar ASP.NET Core como backend, escoger estrategias de renderizado por componente, ejecutar .NET en el navegador cuando tiene sentido y conservar la posibilidad de integrar JavaScript cuando sea necesario.

Sobre todo, me permite modernizar sin fingir que todo lo desarrollado anteriormente carece de valor.

Conclusión: no se trata de Blazor contra React

Quizás esa sea finalmente la conclusión más importante.

React y Blazor no necesitan enfrentarse como si uno tuviera que destruir al otro.

React continuará siendo durante bastante tiempo una de las plataformas dominantes del desarrollo web. Sus cifras, su ecosistema y su comunidad lo demuestran.

La cuestión es que dominio de mercado y conveniencia arquitectónica no son sinónimos.

Para equipos cuya experiencia, infraestructura y lógica empresarial ya viven dentro de .NET, Blazor sobre .NET 10 se ha convertido en una alternativa suficientemente madura como para que elegir React por simple inercia deje de ser una decisión automática.

Yo empecé programando cuando el programa debía viajar físicamente en una tarjeta perforada hasta una computadora.

Hoy puedo ejecutar C# dentro de un navegador mediante WebAssembly.

El cambio tecnológico entre ambos extremos es extraordinario.

Pero después de todos estos años sigo buscando exactamente lo mismo: código comprensible, reglas claras, datos consistentes y sistemas que continúen funcionando mucho después de que haya desaparecido la moda con la que fueron construidos.

Por eso, en 2026, mi pregunta ya no es si Blazor puede competir con React.

La pregunta que me hago es otra:

teniendo casi medio siglo de experiencia y una enorme inversión acumulada en .NET, ¿qué razón tendría para abandonar todo ese capital tecnológico si ahora puedo llevarlo conmigo a la web?

Y, al menos para mis próximos desarrollos, creo que ya tengo la respuesta.

Conversatorio: Blazor, .NET 10 y el futuro del desarrollo empresarial

Como complemento a este ensayo, preparé un breve conversatorio en audio en el que se analizan las ideas centrales del artículo desde una perspectiva más dinámica: la vigencia de React, la madurez alcanzada por Blazor, el valor de mantener C# de extremo a extremo y el papel que jugará la inteligencia artificial en la ingeniería de software de los próximos años.

Más que repetir lo ya expuesto, la conversación busca poner estas decisiones en perspectiva y plantear una pregunta práctica: ¿qué arquitectura tiene más sentido cuando se parte de años de experiencia, código y conocimiento acumulado en el ecosistema .NET?

Fuentes principales

• Microsoft .NET Support Policy: .NET 10 es LTS, publicado el 11 de noviembre de 2025 y con soporte hasta noviembre de 2028.
• Microsoft Learn, C# 14: documentación oficial de field, extension members, asignación condicional nula y conversiones de Span<T>.
• Microsoft Learn, Blazor: modos Static Server, Interactive Server, Interactive WebAssembly e Interactive Auto.
• Microsoft Learn, WebAssembly AOT: beneficios y costo de tamaño de la compilación AOT.
• ASP.NET Core 10: Server-Sent Events, OpenAPI 3.1 y novedades de Blazor.
• Stack Overflow Developer Survey 2025: utilización de React y Blazor, adopción de IA, confianza y dificultades con código generado.
• Aspire 13.4: evolución de la plataforma de orquestación y aplicaciones distribuidas.