Introducción a Blazor para desarrolladores de ASP.NET Web Forms

Sugerencia

Este contenido es un extracto del libro electrónico "Blazor for ASP.NET Web Forms Developers for Azure" (Blazor para desarrolladores de ASP.NET Web Forms), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

El marco ASP.NET Web Forms ha sido una pieza básica del desarrollo web de .NET desde que .NET Framework se publicó por primera vez en 2002. Por aquel entonces, durante los inicios de la web, ASP.NET Web Forms permitía crear aplicaciones web de forma sencilla y productiva, mediante la adopción de muchos de los patrones que se usaban para el desarrollo de aplicaciones de escritorio. En ASP.NET Web Forms, las páginas web se pueden crear rápidamente a partir de controles de interfaz de usuario reutilizables. Las interacciones del usuario se administran de forma natural como eventos. Existe un completo ecosistema de controles de interfaz de usuario de ASP.NET Web Forms proporcionados por Microsoft y proveedores de controles. Los controles facilitan los esfuerzos de conectarse a orígenes de datos y mostrar visualizaciones de datos enriquecidas. Para los que prefieran el aspecto visual, el diseñador de Web Forms proporciona una sencilla interfaz de arrastrar y colocar para administrar controles.

A lo largo de los años, Microsoft ha incorporado nuevos marcos web basados en ASP.NET para abordar las tendencias de desarrollo web. Algunos de estos marcos web incluyen ASP.NET MVC, ASP.NET Web Pages y, más recientemente, ASP.NET Core. Con cada marco nuevo, algunos han vaticinado el declive inminente de ASP.NET Web Forms y lo han criticado por ser un marco web obsoleto y desfasado. A pesar de estas predicciones, muchos desarrolladores web de .NET todavía consideran a ASP.NET Web Forms una forma sencilla, estable y productiva de realizar el trabajo.

En el momento de redactar este artículo, prácticamente medio millón de desarrolladores web usan formularios ASP.NET Web Forms cada mes. El marco ASP.NET Web Forms es estable hasta el punto que la documentación, los ejemplos, los libros y las entradas de blog de hace una década siguen siendo útiles y relevantes. Para muchos desarrolladores web de .NET, "ASP.NET" sigue siendo sinónimo de "ASP.NET Web Forms", tal y como era cuando se diseñó .NET por primera vez. Los argumentos sobre las ventajas y desventajas de ASP.NET Web Forms en comparación con los otros marcos web de .NET modernos pueden ser encendidos. ASP.NET Web Forms sigue siendo un marco popular para la creación de aplicaciones web.

Aún así, las innovaciones en el desarrollo de software no se ralentizan. Todos los desarrolladores de software deben mantenerse al día de las nuevas tecnologías y tendencias. Merece la pena destacar dos tendencias concretas:

1. El cambio a código abierto y multiplataforma
2. El cambio de la lógica de la aplicación al cliente

.NET de código abierto y multiplataforma

Cuando aparecieron .NET y ASP.NET Web Forms, el ecosistema de plataformas era mucho más diferente de lo que existe en la actualidad. Windows dominaba los mercados de productos de escritorio y servidor. Plataformas alternativas como macOS y Linux todavía tenían que esforzarse por hacerse un hueco. ASP.NET Web Forms se distribuye con e .NET Framework como un componente exclusivo para Windows, lo que significa que las aplicaciones de ASP.NET Web Forms solo se pueden ejecutar en máquinas con Windows Server. Ahora en muchos entornos modernos se usan diferentes tipos de plataformas para servidores y máquinas de desarrollo, de modo que para muchos usuarios la compatibilidad entre plataformas es un requisito absoluto.

La mayoría de los marcos web modernos ahora también son de código abierto, lo que ofrece numerosas ventajas. Los usuarios no están limitados a un único propietario del proyecto para corregir errores y agregar características. Los proyectos de código abierto proporcionan una mayor transparencia en el progreso del desarrollo y los cambios futuros. Los proyectos de código abierto disfrutan de contribuciones de una comunidad completa y fomentan un ecosistema de código abierto colaborativo. A pesar de los riesgos del código abierto, muchos consumidores y colaboradores han encontrado mitigaciones adecuadas que les permiten disfrutar de las ventajas de un ecosistema de código abierto de forma segura y razonable. Algunos ejemplos de estas mitigaciones son los contratos de licencia de colaborador, las licencias descriptivas, los exámenes de pedigrí y las bases de soporte.

En la comunidad de .NET se ha adoptado la compatibilidad entre plataformas y el código abierto. .NET Core es una implementación multiplataforma y de código abierto de .NET que se ejecuta en una gran cantidad de plataformas, como Windows, macOS y diversas distribuciones de Linux. Xamarin proporciona Mono, una versión de código abierto de .NET. Mono se ejecuta en Android, iOS y otros factores de forma, incluidos relojes y televisores inteligentes. En 2020, Microsoft publicó .NET 5 que combina .NET Core y Mono en "un solo entorno de ejecución y marco de .NET que se puede usar en cualquier lugar y que tiene comportamientos de tiempo de ejecución y experiencias del desarrollador uniformes".

¿Se beneficiará ASP.NET Web Forms de la evolución hacia la compatibilidad multiplataforma y el código abierto? Desafortunadamente la respuesta es no, o al menos no con el mismo alcance que el resto de la plataforma. El equipo de .NET ha aclarado que ASP.NET Web Forms no se portará a NET Core ni a .NET 8. ¿A qué se debe?

En los inicios de .NET Core hubo esfuerzos por trasladar ASP.NET Web Forms. Se comprobó que el número de cambios importantes necesarios era demasiado drástico. También se reconoce que, incluso para Microsoft, existe un límite en cuanto al número de marcos web que puede admitir simultáneamente. Es posible que alguien de la comunidad asuma la iniciativa de crear una versión multiplataforma y de código abierto de ASP.NET Web Forms. El código fuente de ASP.NET Web Forms se ha puesto a disposición pública en forma de referencia. Pero, por el momento, parece que ASP.NET Web Forms seguirá siendo exclusivo para Windows y no tendrá un modelo de contribución de código abierto. Si la compatibilidad multiplataforma o el código abierto son importantes para los escenarios, tendrá que buscar algo nuevo.

¿Esto significa que ASP.NET Web Forms está inactivo y ya no se debe usar? Evidentemente no. Mientras que .NET Framework se distribuya como parte de Windows, ASP.NET Web Forms será un marco compatible. Para muchos desarrolladores de Web Forms, la falta de compatibilidad multiplataforma y de código abierto no es un problema. Si no necesita compatibilidad con multiplataforma, código abierto ni ninguna de las demás características nuevas de .NET Core o .NET 8, puede seguir usando ASP.NET Web Forms en Windows sin problema. ASP.NET Web Forms seguirá siendo una manera productiva de escribir aplicaciones web durante muchos años.

Pero hay otra tendencia que merece la pena tener en cuenta: el cambio al cliente.

Desarrollo web del lado cliente

Todos los marcos web basados en .NET, incluido ASP.NET Web Forms, han tenido históricamente algo en común: se representan en el servidor. En las aplicaciones web representadas en el servidor, el explorador realiza una solicitud al servidor, que ejecuta código (código de .NET en las aplicaciones ASP.NET) para generar una respuesta. Esa respuesta se devuelve al explorador para que la controle. En este modelo, el explorador se usa como un motor de representación ligero. El trabajo duro de crear la interfaz de usuario, ejecutar la lógica de negocios y administrar el estado tiene lugar en el servidor.

Pero los exploradores se han convertido en plataformas versátiles. Implementan un número cada vez mayor de estándares web abiertos que conceden acceso a las funciones de la máquina del usuario. ¿Por qué aprovechar la potencia de proceso, el almacenamiento, la memoria y otros recursos del dispositivo cliente? En concreto, las interacciones de la interfaz de usuario se pueden beneficiar de una sensación más interactiva y enriquecida cuando se administran de forma parcial (al menos) o total en el lado cliente. La lógica y los datos que se deben administrar en el servidor todavía se pueden controlar en el lado servidor. Se pueden usar llamadas API web o incluso protocolos en tiempo real, como WebSockets. Estas ventajas están disponibles para los desarrolladores web de forma gratuita si están dispuestos a escribir JavaScript. Los marcos de interfaz de usuario del lado cliente, como Angular, React y Vue, simplifican el desarrollo web del lado cliente y han crecido en popularidad. Los desarrolladores de ASP.NET Web Forms también pueden beneficiarse del uso del cliente e incluso contar con la compatibilidad de serie con marcos de JavaScript integrados como ASP.NET AJAX.

Pero la combinación de dos plataformas y ecosistemas diferentes (.NET y JavaScript) tiene un precio. Se necesita experiencia en dos mundos paralelos con diferentes lenguajes, marcos y herramientas. El código y la lógica no se pueden compartir fácilmente entre el cliente y el servidor, lo que produce una sobrecarga de ingeniería y duplicación. También puede ser difícil mantenerse al día con el ecosistema de JavaScript, que tiene un historial de evolución a velocidad de vértigo. Las preferencias de marco de front-end y herramientas de compilación cambian rápidamente. El sector ha observado la progresión desde Grunt a Gulp y luego a Webpack, etc. El mismo ritmo vertiginoso se ha producido en marcos de front-end como jQuery, Knockout, Angular, React y Vue. Pero dado el monopolio de JavaScript en los exploradores, había pocas opciones al respecto. Es decir, hasta que la comunidad web se reunió y consiguió que se produjera un milagro.

WebAssembly satisface una necesidad

En 2015, los principales proveedores de exploradores aunaron fuerzas en un grupo de la comunidad de W3C para crear un nuevo estándar abierto denominado WebAssembly. WebAssembly es un código de bytes para la web. Si puede compilar el código en WebAssembly, se puede ejecutar en cualquier explorador de cualquier plataforma prácticamente a velocidad nativa. Los esfuerzos iniciales se centraron en C/C++. El resultado fue una increíble demostración de la ejecución de motores gráficos 3D nativos directamente en el explorador sin complementos. Desde entonces, WebAssembly se ha normalizado e implementado en los principales exploradores.

El trabajo para ejecutar .NET en WebAssembly se anunció a finales de 2017 y se publicó en 2020, incluida la compatibilidad de .NET 5 y versiones posteriores. La capacidad de ejecutar código de .NET directamente en el explorador permite el desarrollo web de pila completa con .NET.

Blazor: desarrollo web de pila completa con .NET

Por sí misma, la capacidad de ejecutar código de .NET en un explorador no proporciona una experiencia de un extremo a otro para crear aplicaciones web del lado cliente. Aquí es donde Blazor entra en juego. Blazor es una plataforma de interfaz de usuario web del lado cliente basada en C#, en lugar de JavaScript. Blazor se puede ejecutar directamente en el explorador mediante WebAssembly. No se necesitan complementos de explorador. Como alternativa, las aplicaciones Blazor se pueden ejecutar en el lado servidor en .NET y controlar todas las interacciones del usuario por medio de una conexión en tiempo real con el explorador.

Blazor tiene una gran compatibilidad con las herramientas en Visual Studio y Visual Studio Code. El marco también incluye un modelo completo de componentes de interfaz de usuario y tiene funciones integradas para lo siguiente:

• Formularios y validación
• Inserción de dependencias
• Enrutamiento del lado cliente
• Diseños
• Depuración en el explorador
• Interoperabilidad de JavaScript

Blazor tiene mucho en común con ASP.NET Web Forms. Los dos marcos ofrecen modelos de programación de interfaz de usuario con estado basados en componentes, controlados por eventos. La principal diferencia arquitectónica es que ASP.NET Web Forms solo se ejecuta en el servidor. Blazor se puede ejecutar en el cliente en el explorador. Pero si proviene de ASP.NET Web Forms, hay muchos aspectos de Blazor que le resultarán familiares. Blazor es una solución natural para los desarrolladores de ASP.NET Web Forms que buscan una manera de aprovechar el desarrollo del lado cliente y el futuro multiplataforma y de código abierto de .NET.

En este libro se proporciona una introducción a Blazor que se ofrece específicamente a los desarrolladores de ASP.NET Web Forms. Cada concepto de Blazor se presenta en el contexto de las características y los procedimientos análogos de ASP.NET Web Forms. Al final de este libro, tendrá conocimientos sobre:

• Cómo compilar aplicaciones Blazor.
• Cómo funciona Blazor.
• Cómo se relaciona Blazor con .NET.
• Estrategias razonables para realizar la migración de aplicaciones de ASP.NET Web Forms existentes a Blazor cuando corresponda.

Introducción a los Blazor

Empezar a trabajar con Blazor es sencillo. Vaya a https://blazor.net y siga los vínculos para instalar el SDK de .NET adecuado y las plantillas de proyecto de Blazor. También encontrará instrucciones para configurar las herramientas de Blazor en Visual Studio o Visual Studio Code.

AnteriorSiguiente