Este tema lo he debatido con colegas en varias ocasiones y creo que abordarlo aquí puede resultar interesante para algunos más que os estéis preguntando lo mismo a raíz de la tracción que, poco a poco, va tomando Blazor entre los desarrolladores web que trabajamos con el stack de tecnologías de Microsoft.

Voy a explicar mi punto de vista al respecto contemplando dos aspectos distintos, que creo que son los fundamentales para poder responder apropiadamente a esta pregunta:

• Si técnicamente sería posible reemplazar MVC por Blazor, esto es, si Blazor dispone de mecanismos suficientes para cubrir las necesidades de una aplicación que tradicionalmente se desarrollaría con MVC.
• Si la popularidad y difusión de Blazor podría llegar a alcanzar las cotas suficientes para convertirse en una alternativa completa y segura a MVC, en términos de madurez, estabilidad, soporte y tamaño de la comunidad. O en otras palabras, si Blazor como producto llegará a estar lo suficientemente consolidado como para poder reemplazar a MVC.

Vamos a analizar cada una de ellas.

Disclaimer: obviamente, todo lo que veréis a continuación son opiniones personales y, como tales, pueden ser discutibles. Si tenéis una opinión diferente, estaré encantado de leerla en los comentarios.

¿Es técnicamente viable reemplazar MVC por Blazor?

Hasta ASP.NET Core 8, Blazor estaba enfocado exclusivamente al desarrollo de aplicaciones Single Page Application (SPA), es decir, aplicaciones web que se ejecutan por completo en el navegador y que frecuentemente se comunican con un servidor para obtener datos y servicios. En este sentido, Blazor era una alternativa a Angular, React o Vue, entre otros, y no a frameworks de backend como ASP.NET Core MVC o Razor Pages. Simplemente, jugaban en ligas distintas.

Sin embargo, con la llegada de las Blazor Web Apps en ASP.NET Core 8, la cosa ha cambiado bastante. Blazor ahora puede utilizarse para desarrollar aplicaciones web tradicionales, en las que el código se ejecuta en el servidor, enviando el resultado HTML al navegador. Vaya, como los frameworks de backend de toda la vida.

Gracias a esta nueva posibilidad, denominada Server-Side Rendering, Blazor puede cubrir un espectro de aplicaciones web mucho más amplio, y probablemente podría reemplazar a MVC sin problema. De hecho, en muchos aspectos, Blazor puede ser una opción más atractiva para muchos desarrolladores debido a su facilidad de uso y la productividad que proporciona su modelo de componentes, a algunas funcionalidades chulas (como el stream rendering o la navegación mejorada) y porque en muchos casos podría eliminar el JavaScript que necesitamos para implementar funcionalidades habituales funcionalidades en cliente (de hecho, es rara la aplicación MVC que no tenga que usar JavaScript para añadir funcionalidades en frontend).

Técnicamente, en aplicaciones web, Blazor podría reemplazar por completo a las capas "V" y "C" de "MVC", es decir, la Vista y el Controlador. El Modelo podría seguir siendo el mismo, porque ni Blazor ni MVC son prescriptivos en este sentido.

Una de las principales ventajas de Blazor respecto a MVC para la implementación de estas capas es su sencillez. En MVC, a veces resulta tedioso tener que crear y gestionar tantos artefactos para realizar tareas simples; por ejemplo, crear un controlador, una acción y una vista (en su carpeta correspondiente por convención) para mostrar una página sería mucho más sencillo en Blazor, donde crearíamos un único archivo que une la interfaz y la lógica de presentación.

MVC, gracias a su madurez, había ido incorporando herramientas para mejorar nuestra productividad durante la creación de vistas y componentes de interfaz, como los layouts, tag helpers, html helpers, view components, partial views o secciones. Todos ellos tienen su equivalente en Blazor, así que el salto a esta tecnología no supone la pérdida de estas funcionalidades.

Pero además, el modelo de componentes de Blazor es una pasada, y cuando empezamos a trabajar con él nos hace sentirnos especialmente productivos por lo fácil que resulta crearlos y reutilizarlos.

Tanto en MVC como en Blazor, el sistema de routing corre sobre la misma infraestructura (el sistema de routing de ASP.NET Core), por lo que en la mayoría de los escenarios podremos lograr lo mismo. Las páginas creadas con Blazor declaran sus propias rutas que, como en los demás casos, pueden contener porciones parametrizables y restricciones (constraints) predefinidas o personalizadas.

Blazor también proporciona su sistema de binding, que permite enlazar datos con la interfaz de usuario de forma muy sencilla gracias al uso del patrón MVVM. A la hora de escribir formularios, se utilizan las mismas data annotations que en MVC para validaciones automáticas y, por tanto, disponen de los mismos mecanismos de extensibilidad.

También es posible inyectar dependencias en los componentes de Blazor, lo que nos permite seguir trabajando con el patrón al que ya estamos acostumbrados al usar MVC.

Pero bueno, tampoco es oro todo lo que reluce 😉 Hay características de MVC que no pueden ser implementadas en Blazor, o al menos de forma sencilla.

Por ejemplo, en Blazor no disponemos de filtros (al menos no en el sentido en el que los usamos en MVC). No podemos controlar muy detalladamente las  peticiones entrantes (por ejemplo, definir distintos manejadores en función del verbo HTTP), pero no lo necesitaremos para los objetivos de Blazor. Tampoco tenemos tipos de resultado distintos (IActionResult de MVC), caché de resultados integrado, o control fino sobre las respuestas como podríamos tener con este marco de trabajo.

La implementación o configuración de un sistema de autenticación no está demasiado bien resuelta de momento. Aunque previsiblemente esto mejorará en la siguiente versión (noviembre), Blazor en ASP.NET Core 8 viene algo cortito en esto, principalmente debido a los modelos de hosting y la forma en que pueden coexistir en los proyectos.

Y, por supuesto, Blazor no nos valdrá para crear APIs: no es su misión. Para eso, tendremos que seguir recurriendo a MVC o a las minimal APIs.

Bueno, probablemente se me escapen cosas, pero creo que con lo comentado hasta el momento ya podríamos ver que MVC sería técnicamente reemplazable por Blazor en muchos escenarios. Es decir, hay aplicaciones que podríamos escribirlas indistintamente usando cualquiera de las dos opciones.

Pero aparte, Blazor ofrece posibilidades fuera del alcance de MVC, que tradicionalmente teníamos que complementar usando JavaScript. Con Blazor no sólo renderizaremos el HTML en el servidor, sino que podremos implementar ricos componentes interactivos ejecutados en el navegador, usando únicamente (o como mínimo, principalmente) C#.

¿Blazor se acabará ganando la confianza de los desarrolladores?

Está claro que, a día de hoy, Blazor no está tan difundido ni es tan popular como otras opciones con más trayectoria, y esto podría introducir un cierto grado de desconfianza a la hora de apostar en él para sustituir a nuestro querido MVC.

Hay que tener en cuenta que Blazor SSR, lo que técnicamente podría ser la alternativa real a MVC, lleva con nosotros sólo unos meses y, por tanto, no hemos tenido tiempo apenas para conocer todo su potencial y tomarle cariño 😉. Las versiones de Blazor disponibles hasta el momento competían en el mundo de las SPA (Angular, React...) y, por tanto, no eran equiparables a MVC ni podría haber optado nunca a reemplazarlo.

Salvo que tengamos una bola de cristal bien pulida, es imposible predecir el futuro y saber qué ocurrirá, así que de momento lo único que podemos hacer es interpretar las señales:

• Está claro que la apuesta de Microsoft por Blazor es fuerte, y viene demostrando en las últimas versiones de ASP.NET Core lanzadas. La cantidad de novedades (y, por tanto, entiendo que recursos dedicados) a Blazor es muy superior a las que van apareciendo en otros frameworks tradicionales como MVC o Razor Pages.
• Sigue habiendo grandes planes para el futuro. Si a día de hoy echamos un vistazo al roadmap de ASP.NET Core 9 (previsto para noviembre de 2024), podremos comprobar que la mayoría de features pertenecen a Blazor.
• Oficialmente, Blazor es la opción recomendada para la mayoría de escenarios de interfaz de usuario web (ver entrada de Microsoft Learn o comentario de Dan Roth al respecto).
• La comunidad de desarrolladores Blazor está creciendo, y cada vez hay más gente trabajando ya e interesada en aprenderlo, lo que se traduce en más contenidos, más bibliotecas, más ejemplos, más frameworks y más herramientas, tanto proporcionadas por Microsoft como por terceros. Aunque, por supuesto, de momento su popularidad sigue siendo inferior a lo que podemos encontrar en otros marcos de trabajo.
• El ámbito de aplicación de Blazor sigue creciendo. Quizás lo más visible últimamente ha sido la introducción de las Blazor Web Apps y el modelo unificado de componentes, que ha permitido a Blazor no sólo enfocarse al desarrollo de aplicaciones SPA, sino también al de las aplicaciones web tradicionales ejecutadas en servidor. Y no hay que olvidar su potencial uso en otros entornos, como aplicaciones de escritorio o móviles.
• Aunque se ha complicado un poco últimamente, la facilidad de aprendizaje y uso de Blazor es bien conocida. La curva de aprendizaje es relativamente suave, y muchos desarrolladores que ya conocen la web, C# y .NET pueden empezar a trabajar con Blazor en poco tiempo, especialmente los desarrolladores ASP.NET Core MVC y Razor Pages, porque ya conocen la sintaxis Razor,  usada en componentes Blazor. Esto es un factor clave para que la adopción de la tecnología aumente.
• Creo que ya ha desaparecido el fantasma "Silverlight". El lastre de esta difunta tecnología persiguió a Blazor desde sus inicios, porque muchos desarrolladores pensaron que podrían seguir una trayectoria similar. Afortunadamente, creo que ya ha quedado claro que son cosas distintas, y que el momento es distinto también (recordemos que Silverlight fue una víctima de su tiempo, como otras tecnologías similares que coexistieron con él, como Flash o los Applets Java).

A la vista de esto, todo apunta a que Blazor podría llegar a convertirse en un producto consolidado y una alternativa real a MVC en un futuro quizás no muy lejano. Pero como decía antes, no hay certezas, y habrá que esperar a ver cómo evoluciona la tecnología y su grado de adopción en la industria.

En conclusión

Atendiendo a la mayoría de estos aspectos, parece que Blazor tiene un futuro prometedor y, por todo lo que hemos comentado antes, tiene potencial para reemplazar a MVC en muchos escenarios.

En cualquier caso, esto no implicaría la desaparición de MVC o Razor Pages, ni mucho menos. Se trata simplemente de disponer de opciones, poder elegir entre distintos caminos para llegar a un mismo destino: la construcción de aplicaciones web. También hay que tener en cuenta que Blazor no cubre necesidades frecuentes, como la construcción de APIs, algo para lo que tendríamos que seguir recurriendo a MVC o minimal APIs, por lo que estos marcos de trabajo seguirán siendo necesarios. La elección de uno u otro dependerá de las necesidades concretas de cada proyecto, posibilidades de reutilización de otros proyectos, las preferencias del equipo de desarrollo, la experiencia previa y de otros muchos factores.

Pero en mi opinión, la evolución de todo esto, al menos a corto-medio plazo, será la convivencia. Por suerte, Blazor, MVC, Razor Pages, minimal APIs y otros frameworks basados en ASP.NET Core están diseñados para trabajar bien juntos, y no hay nada que impida mezclarlos en un mismo proyecto si es lo que necesitamos. De hecho, esto permitiría a los equipos de desarrollo elegir la tecnología que mejor se adapte a cada parte de la aplicación o en la que puedan ser más productivos, y no tener que ceñirse a un único framework para todo.

Y vosotros, ¿qué opináis? ¿Creéis que Blazor podría reemplazar a MVC en un futuro? ¿O pensáis que MVC seguirá siendo la opción preferida para muchos desarrolladores? ¡Espero vuestros comentarios!

<Spam>Por cierto, si os estáis planteando aprender Blazor, ya estáis tardando en echarle un vistazo a mi curso de Blazor en CampusMVP. Pero si preferís MVC, también podéis poneros las pilas con mi curso Desarrollo de aplicaciones Web con ASP.NET Core y MVC😉</Spam>

Publicado en Variable not found.