Introducción a Blazor para desarrolladores de formularios web de ASP.NET

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 de ASP.NET Web Forms ha sido un elemento básico del desarrollo web de .NET desde que .NET Framework se envió por primera vez en 2002. De nuevo, cuando la Web todavía estaba en su infancia, ASP.NET Web Forms hizo que la creación de aplicaciones web sea sencilla y productiva mediante la adopción de muchos de los patrones que se usaron para el desarrollo de escritorio. En ASP.NET Web Forms, las páginas web se pueden componer rápidamente a partir de controles de interfaz de usuario reutilizables. Las interacciones del usuario se controlan de forma natural como eventos. Hay un amplio ecosistema de controles de interfaz de usuario de Formularios Web Forms proporcionados por Microsoft y proveedores de control. Los controles facilitan los esfuerzos de conectarse a orígenes de datos y mostrar visualizaciones de datos enriquecidas. Para los que prefieren lo visual, el diseñador de Web Forms proporciona una sencilla interfaz de arrastrar y soltar para administrar controles.

A lo largo de los años, Microsoft ha introducido 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 nuevo framework, algunos han pronosticado la inminente desaparición de ASP.NET Web Forms y lo han criticado como un marco web anticuado y obsoleto. A pesar de estas predicciones, muchos desarrolladores web de .NET siguen buscando ASP.NET Web Forms una manera sencilla, estable y productiva de realizar su trabajo.

En el momento de escribirlo, casi medio millón de desarrolladores web usan ASP.NET formularios web cada mes. El marco de web Forms de ASP.NET es estable hasta el punto de que los documentos, ejemplos, libros y 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" como era cuando .NET se concibió por primera vez. Los argumentos sobre las ventajas y desventajas de ASP.NET Web Forms en comparación con otros nuevos marcos web de .NET pueden continuar intensamente. ASP.NET Web Forms sigue siendo un marco popular para crear aplicaciones web.

Incluso así, las innovaciones en el desarrollo de software no se ralentizan. Todos los desarrolladores de software necesitan mantenerse al día de las nuevas tecnologías y tendencias. Cabe tener en cuenta dos tendencias en particular:

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

Un .NET multiplataforma y de código abierto

Cuando .NET y ASP.NET Web Forms fueron lanzados por primera vez, el ecosistema de plataformas era muy diferente al de hoy en día. Los mercados de escritorio y servidor estaban dominados por Windows. Las plataformas alternativas como macOS y Linux todavía estaban luchando por ganar tracción. ASP.NET Web Forms se incluye con .NET Framework como componente exclusivo para Windows, lo que significa que las aplicaciones ASP.NET Web Forms solo se pueden ejecutar en servidores Windows. Muchos entornos modernos ahora usan diferentes tipos de plataformas para servidores y máquinas de desarrollo, de modo que la compatibilidad multiplataforma con muchos usuarios es un requisito absoluto.

La mayoría de los marcos web modernos ahora también son de código abierto, lo que tiene una serie de 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 próximos cambios. Los proyectos de código abierto disfrutan de contribuciones de toda una comunidad y fomentan un ecosistema de código abierto de apoyo. A pesar de los riesgos de 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 una manera 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.

La comunidad de .NET ha adoptado compatibilidad multiplataforma y 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 varias distribuciones de Linux. Mono es una versión de código abierto de .NET que se ejecuta en Android, iOS y una variedad de otros formatos, incluidos relojes y televisores inteligentes. En 2020, Microsoft lanzó .NET 5 que concilió .NET Core y Mono en "un único entorno de ejecución y marco de .NET que se puede usar en todas partes y que tiene comportamientos uniformes en tiempo de ejecución y experiencias de desarrollador".

¿Se beneficiará ASP.NET Web Forms del traslado a compatibilidad multiplataforma y de código abierto? La respuesta, desafortunadamente, es no, o, al menos, no en la misma medida que el resto de la plataforma. El equipo de .NET dejó claro que ASP.NET Web Forms no se migrará a .NET Core ni a .NET 8. ¿Por qué ocurre esto?

Hubo esfuerzos en los primeros días de .NET Core para migrar ASP.NET Web Forms. Se comprobó que el número de cambios importantes necesarios era demasiado drástico. También hay una admisión aquí que incluso para Microsoft, hay un límite para el número de marcos web que puede admitir simultáneamente. Quizás alguien de la comunidad asumirá la causa de crear una versión de ASP.NET Web Forms que sea multiplataforma y de código abierto. El código fuente de ASP.NET Web Forms se ha puesto a disposición públicamente en forma de referencia. Pero por el momento, parece que ASP.NET Web Forms seguirá siendo solo Windows y sin un modelo de contribución de código abierto. Si la compatibilidad multiplataforma o el código abierto son importantes para sus escenarios, deberá buscar algo nuevo.

¿Esto significa que ASP.NET formularios web está inactivo y ya no se debe usar? ¡Claro que no! Siempre que .NET Framework se incluya 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 tiene ningún requisito para la compatibilidad multiplataforma, el código abierto o ninguna de las otras características nuevas de .NET Core o .NET 8, después seguir con ASP.NET Web Forms en Windows es correcto. 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 y eso es el cambio al cliente.

Desarrollo web del lado cliente

Todos los marcos web basados en .NET, incluidos ASP.NET Web Forms, han tenido históricamente una cosa en común: se renderizan en el servidor. En las aplicaciones web representadas por el servidor, el explorador realiza una solicitud al servidor, que ejecuta algún código (código .NET en ASP.NET aplicaciones) para generar una respuesta. Esa respuesta se devuelve al navegador para gestionarla. En este modelo, el explorador se usa como un motor de representación fino. El trabajo duro de generar la interfaz de usuario, ejecutar la lógica de negocios y administrar el estado se produce en el servidor.

Sin embargo, 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 funcionalidades de la máquina del usuario. ¿Por qué no aprovechar la potencia de proceso, el almacenamiento, la memoria y otros recursos del dispositivo cliente? Las interacciones de la interfaz de usuario en particular pueden beneficiarse de una sensación más enriquecida y más interactiva cuando se administran al menos parcialmente o completamente en el lado cliente. La lógica y los datos que deben manejarse en el servidor todavía pueden gestionarse del lado del servidor. Se pueden usar llamadas a 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 el puente entre dos plataformas y ecosistemas diferentes (.NET y JavaScript) conlleva un costo. La experiencia es necesaria 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 da lugar a la sobrecarga de duplicación e ingeniería. También puede ser difícil mantenerse al día con el ecosistema de JavaScript, que tiene un historial de evolución a velocidad vertiginosa. Las preferencias de la herramienta de compilación y el marco de front-end cambian rápidamente. La industria ha observado la progresión de Grunt a Gulp a Webpack, etc. El mismo ritmo vertiginoso se ha producido en marcos de front-end como jQuery, Knockout, Angular, React y Vue. Sin embargo, dado el monopolio del explorador de JavaScript, había poca opción en el asunto. Es decir, hasta que la comunidad web se reunió y causó que un milagro sucediera.

WebAssembly satisface una necesidad

En 2015, los principales proveedores de exploradores se unieron a las fuerzas de un grupo de la comunidad W3C para crear un nuevo estándar web abierto denominado WebAssembly. WebAssembly es un código de bytes para la Web. Si puede compilar el código en WebAssembly, puede ejecutarse en cualquier explorador de cualquier plataforma a una velocidad nativa cercana. Los esfuerzos iniciales se centraron en C/C++. El resultado fue una demostración dramática de la ejecución de motores gráficos 3D nativos directamente en el explorador sin complementos. WebAssembly desde entonces ha sido estandarizado e implementado por todos los exploradores principales.

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 completo con .NET

Por su cuenta, la capacidad de ejecutar código .NET en un explorador no proporciona una experiencia de un extremo a otro para crear aplicaciones web del lado cliente. Ahí es donde Blazor entra. Blazor es un marco de interfaz de usuario web del lado cliente basado en C# en lugar de JavaScript. Blazor puede ejecutarse directamente en el explorador a través de WebAssembly. No se requieren complementos de explorador. Como alternativa, las Blazor aplicaciones pueden ejecutar el lado servidor en .NET y controlar todas las interacciones del usuario a través de una conexión en tiempo real con el explorador.

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

• Formularios y validación
• Inserción de dependencia
• 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. Ambos 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 viene de una experiencia en ASP.NET Web Forms, hay mucho en Blazor que le resultará familiar. Blazor es una solución natural para ASP.NET desarrolladores de Web Forms que buscan una manera de aprovechar el desarrollo del lado cliente y el futuro multiplataforma de código abierto de .NET.

Este libro proporciona una introducción a Blazor orientada específicamente a desarrolladores de ASP.NET Web Forms. Cada Blazor concepto se presenta en el contexto de características y prácticas análogas de ASP.NET Web Forms. Al final de este libro, comprenderá lo siguiente:

• Cómo crear Blazor aplicaciones.
• Cómo Blazor funciona.
• Cómo Blazor se relaciona con .NET.
• Estrategias razonables para migrar aplicaciones existentes de ASP.NET Web Forms a Blazor cuando corresponda.

Empieza con Blazor

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

Siguiente anterior