Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

Introducción a Blazor a través de 7 preguntas (y sus respuestas)

Imagen de portada, ornamental

Los desarrolladores que trabajamos con tecnologías web de Microsoft estamos viviendo un terremoto con la llegada de Blazor. No en vano, Blazor se está postulando como una alternativa real a frameworks para el desarrollo de aplicaciones web ya consolidados, como MVC o Razor Pages, e incluso como sustituto de soluciones SPA como Angular o React.

Sin embargo, aún hay muchos desarrolladores que no han oído hablar de este nuevo marco de trabajo o que tienen algunas dudas sobre él. En este post vamos a intentar responder a algunas preguntas que, aunque básicas, creo que serán interesantes para todos los que queráis echar un primer vistazo a este framework que nos puede cambiar la forma de desarrollar aplicaciones web.

1.- ¿Qué es exactamente Blazor?

Si tuviéramos que definirlo en una única frase corta, quizás podría ser algo como:

Blazor es un framework para la construcción de aplicaciones SPA.

Pero obviamente, hay mucho por detrás de esta escueta descripción. Blazor incluye todo lo que necesitamos para construir aplicaciones profesionales en una única página (SPA) y de calidad:

  • Sistema de componentes
  • Implementación de componentes basada en MVVM
  • Sistema de bindings
  • Sistema de routing
  • Sistema de inyección de dependencias
  • Sistema de gestión de errores
  • Sistema de plantillas para componer la UI
  • Herramientas de compilación
  • Herramientas de depuración
  • ... etc.

Por otra parte, se trata de un proyecto liderado por Microsoft (de hecho, forma parte de ASP.NET Core), pero abierto a la comunidad. Es open source (licencia Apache 2.0) y es posible colaborar en el desarrollo mediante pull requests, reportando issues, ideas, etc.

Si vienes de otros frameworks que tienen el mismo objetivo, como Angular, Vue o React, todas estas características te sonarán porque ya las has visto antes. ¿Nada nuevo bajo el sol? 😉

2.- ¿En qué se diferencia Blazor de otros frameworks SPA como Angular, React o Vue?

Visto el punto anterior, no parece que Blazor aporte mucho sobre los numerosos frameworks existentes que persiguen el mismo fin, la construcción de aplicaciones SPA y que, de hecho, se parecen también bastante entre ellos.

Pero Blazor añade un objetivo, tan ambicioso como atractivo, que es lo que lo hace único: los desarrolladores no tendrán que utilizar JavaScript, sino C#, lo cual aporta ventajas interesantes:

  • Reducir la dificultad inicial con la que se encuentran los profesionales .NET a la hora de empezar a construir aplicaciones SPA.
  • Seguir utilizando el fantástico tooling existente en el ecosistema .NET.
  • Aprovechar y reutilizar código existente también en las capas de presentación.
  • Compartir directamente código entre cliente y servidor.
  • O, por supuesto, las derivadas de la utilización de un lenguaje de primer nivel como C#.

3.- Pero si uso C# para programar mi SPA, ¿ya no puedo usar bibliotecas o código JS existente?

No he dicho eso 😉 De hecho, sería una pena desaprovechar la gran cantidad de bibliotecas, componentes y código que la comunidad JavaScript ha estado aportando a la humanidad durante tantos años.

Aunque Blazor está diseñado para que todo lo implementemos con C#, existen "puentes" que permiten utilizar JavaScript en dos direcciones, de forma que podemos aprovechar lo mejor de ambos mundos:

  • Desde código Blazor (C#) podemos invocar funciones JS.
  • Desde código JS podemos invocar métodos Blazor (C#)

Por ejemplo, si nos gusta Bootstrap, resulta sencillo crear componentes Blazor que encapsulen los componentes de este framework, tanto en lo relativo a presentación (marcado HTML) como el código de métodos y eventos JS que presentan ciertos elementos visuales, como los diálogos modales, pestañas, etc. De esta forma, los consumidores de estos componentes Blazor no tendrán que ver JS en absoluto, interactuarán con Bootstrap directamente desde C#, dando lugar a "componentes nativos Blazor".

4.- ¿Existen bibliotecas de componentes nativos para Blazor?

En efecto, la comunidad Blazor lleva ya tiempo avanzando en el desarrollo de componentes de todo tipo, tanto gratuitos como de pago. Aunque este ecosistema obviamente no es comparable en tamaño al de JavaScript, sí que hay ya un buen número de bibliotecas que prácticamente comprenden las necesidades más habituales.

Es fácil encontrar componentes creados por desarrolladores independientes, fácilmente localizables a través de Google. Por ejemplo, es inmediato descubrir que existen ya varias alternativas para utilizar Bootstrap de forma nativa en Blazor, que ocurre lo mismo con los clásicos grids o rejillas de datos o componentes para lanzar ventanas modales entre muchos otros.

También existen colecciones y suites de componentes, como la gratuita (y extensa) Blazored (+10 componentes), MatBlazor (+40 componentes material design), o la biblioteca de Radzen(+40 componentes), también de uso gratuito.

Si tenemos acceso a soluciones profesionales, también los grandes proveedores de componentes hace tiempo que comenzaron a ofrecer soluciones para Blazor, como por ejemplo:

Componentes DevExpress para Blazor

5.- Espera, C# es un lenguaje de servidor, ¿dónde se ejecuta una aplicación Blazor?

Una de las piezas clave de los frameworks SPA es su capacidad para interactuar con el DOM, que son los elementos que componen las páginas que vemos en nuestro navegador. A priori, esto podría limitar las opciones de Blazor, puesto que para que pudiéramos interactuar con el DOM desde C# haría falta:

  • o bien acercar el DOM al servidor, que es donde tradicionalmente "vive" C#,
  • o buscar una fórmula para que C# vaya al cliente.

Blazor soporta ambas opciones y les da un nombre: Blazor Server y Blazor WebAssembly, respectivamente.

Blazor hosting models

En el primer caso, la aplicación correrá en el lado servidor, sobre ASP.NET Core. El servidor manipulará una representación del DOM en memoria, que mantendrá sincronizada con el browser gracias a una conexión SignalR.

En el segundo, la aplicación Blazor se ejecuta directamente en el navegador sobre un runtime de .NET basado en Mono, que se ejecuta sobre WebAssembly. No necesitas servidor y puedes desplegarla incluso desde almacenamiento (como GitHub pages o Azure Blob Storage).

La primera release oficial de Blazor Server se lanzó junto a .NET Core 3 (septiembre de 2019). La primera versión de Blazor WebAssembly fue liberada algunos meses más tarde, en mayo de 2020.

Lo más interesante es que ambas opciones utilizan el mismo modelo de programación. Es decir, la forma de programar las aplicaciones no cambia, independientemente de si vamos a alojarlas en el cliente o en el servidor. Por tanto, al menos en teoría, podríamos ir cambiando entre uno y otro modelo de forma (casi) transparente... aunque más adelante puntualizaremos este tema 😉

6. Hey, y esto de llevar C# al navegador, ¿no lo he oído antes? 😒

Pues si llevas algunos años en este mundillo, probablemente...

Aunque no tiene que ver directamente con C#, recuerdo que uno de los primeros intentos de Microsoft de llevar uno de sus lenguajes al browser fue con VBScript, allá por el año 1996 (¡sí, Internet existía por entonces!). Para los que no lo hayáis visto, la idea consistía básicamente en introducir código VB en etiquetas <script> de la siguiente forma:

<script language="vbscript">
    MsgBox "Hola, qué tal"
</script>

Esta tecnología, nacida en plena guerra de los navegadores sólo era soportada por Internet Explorer, y sobra decir que perdió la batalla contra JavaScript. Aun así, VBScript ha estado activo y soportado en IE hasta 2019.

Seguro que algunos también recordaréis Silverlight 😰 Fue lanzado en 2007, en pleno apogeo del concepto RIA (rich Internet Applications) como la panacea y el futuro de la web, empujados fuertemente por tecnologías como Flash, Flex, JavaFX y otras opciones similares.

En todos los casos, la idea era "incrustar" en el browser aplicaciones pesadas que corrían sobre un runtime propietario. A día de hoy, podríamos considerar todas estas opciones como intentos frustrados de romper la web tal y como la conocemos en estos momentos. Afortunadamente, la cordura devolvió las aguas a los cauces originales, y los estándares triunfaron. Silverlight fue discontinuado en 2015.

¿Pero, por qué cuento todo esto? Pues para que ahora veáis claro que el caso de Blazor es totalmente diferente. Las dos tecnologías de las que hemos hablado eran completamente cerradas, propietarias y alejadas de estándares, mientras que Blazor WebAssembly se basa en estándares aceptados por la industria y la comunidad, tales como C#, .NET (sí, son estándares del ECMA, igual que JavaScript) y WebAssembly. Esto, junto con el hecho de que Blazor sea un proyecto open source desde sus orígenes, hacen que no exista una dependencia respecto a un proveedor, como ocurría con VBScript o Silverlight.

También ASP.NET Web Forms, tecnología nacida en 2002 junto con .NET, de alguna forma, ofrecía la ilusión de un C# corriendo en el navegador, gracias a la facilidad con la que podíamos implementar en el servidor el handler del evento click de un botón que se encontraba en el browser y las abstracciones sobre el DOM que sustentaban esta tecnología. El problema es que estos mecanismos, además de ser propietarios, nos alejaban de la realidad de la web, algo que poco a poco también fue descartado por la comunidad de desarrolladores.

A nivel funcional, Blazor Server podría parecerse conceptualmente a Web Forms, pues el código C# se encuentra en el servidor, que es donde realmente se procesa la lógica de presentación, para luego enviar de vuelta las modificaciones a realizar en el DOM. De hecho, Blazor Server es la tecnología que propone Microsoft como sustituta de Web Forms, dado que el estilo de desarrollo puede ser conceptualmente muy parecido.

Blazor Server, además de ser código abierto y estar montado sobre estándares, propone un modelo de desarrollo muy respetuoso son la web: maquetamos las páginas con HTML puro, y no se introduce en las páginas código que no queramos (algo que en Web Forms era muy frecuente), ni Viewstates ni nada parecido. También, el hecho de que Blazor sea un framework SPA aporta un extra de calidad bastante importante en la interfaz de usuario.

7.- ¿Qué es esto de WebAssembly?

Vale, pero, ¿qué clase de invento es este de WebAssembly? ¿No será algo parecido a los applets de Java o el antiguo y peligroso Flash? 😱

No. Nada que ver. WebAssembly o Wasm es una especificación estándar del W3C desde diciembre de 2019, y define un formato portátil de código binario para programas ejecutables directamente en el navegador. ¿Y esto qué significa? Pues se trata de una serie de instrucciones de bajo nivel parecidas al lenguaje ensamblador (de ahí su nombre), que permiten que el navegador ejecute aplicaciones binarias del mismo modo que las ejecuta un sistema operativo.

Si te suena qué es el ByteCode de Java, el CIL/MSIL de .NET o el p-code de muchos otros como el de Visual Basic clásico, esto es más o menos lo mismo pero en el entorno del navegador.

Pero esto no quiere decir que te tengas que complicar la vida. Lo que significa es que si tu lenguaje favorito, en este caso C#, tiene un compilador que genere módulos de Wasm, podrás utilizarlo directamente en el navegador con un rendimiento mucho mayor que si usases JavaScript, y sin sus problemas.

De hecho WebAssembly, tras JavaScript, es el segundo lenguaje de programación nativo que entienden y soportan los navegadores sin necesidad de extensiones, plugins ni nada. Todos los navegadores modernos (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari...) lo llevan incluido de serie y no es necesario instalar nada para poder sacarle partido.

Además, permite hacer cosas imposibles o limitadas en JavaScript, como hilos o SIMD (Single Instruction, Multiple Data, que permite ejecutar una instrucción única en varios datos a la vez), lo cual dota de una potencia inédita a los navegadores para llevar a cabo tareas pesadas como edición de vídeo en paralelo, juegos, realidad virtual y otras cosas de bajo nivel o muy demandantes.

Para que te hagas una idea, un caso famoso de implementación ha sido el de la herramienta de diseño actualmente más de moda, Figma, que fueron de los primeros en migrar una aplicación grande a WebAssembly y lograron mejorar el rendimiento en un 300% en una aplicación que ya era mucho más rápida que las creadas con JavaScript. En Figma ya programaban la aplicación en C++ y la compilaban a un precursor de Wasm llamado asm.js, que era mucho más rápido que JavaScript. Pero con Wasm la ganancia todavía es mucho mayor y nos da una idea de la potencia del nuevo lenguaje.

Blazor compila C# a ensamblados, como siempre, y éstos se ejecutan en el navegador sobre el runtime .NET que está previamente compilado para Wasm.

Cerrando preguntas (por ahora)

Con estas 7 preguntas te puedes hacer una composición de lugar de qué es Blazor y cómo se relaciona con la plataforma .NET, con los navegadores y con los servidores, además de tener una idea de la potencia que te puede otorgar para crear aplicaciones Web.

La semana que viene volveré al ataque con otras 7 preguntas y sus respuestas para aprender un poco mejor qué es Blazor desde un punto de vista práctico, y cómo se utiliza.

Mientras tanto, ¿qué te parece Blazor? ¿Lo conocías ya? ¿Has podido probarlo? Déjanos tus impresiones en los comentarios de debajo.

¡Hasta pronto!

José María Aguilar José María atesora una amplísima experiencia trabajando en el mundo del desarrollo de software (programador, analista, responsable de informática, consultor, director técnico), principalmente con tecnologías Microsoft. Actualmente trabaja como consultor y desarrollador independiente, ofreciendo servicios tecnológicos a empresas e instituciones.
Es un reconocido experto en desarrollo web en todo el mundo, y es autor del libro de Microsoft Press "SignalR Programming in Microsoft ASP.NET".
Escribe regularmente artículos sobre ASP.NET MVC y otros temas relacionados con el desarrollo de software en su blog.
Puedes seguirlo en Twitter en @jmaguilar. Ver todos los posts de José María Aguilar
Archivado en: Desarrollo Web

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (7) -

En breve empiezo un proyecto con Blazor, me ha encantado el resumen que has hecho sobre esta tecnología tan genial, enhorabuena!

Responder

Gracias, si de hecho Blazor es fantastico para un desarrollo rapido lo he estado probando (Server Side) y es muy prometedor, solamente estan pendientes algunas cosas como el Debuging y Hot Reload, pero de ahy todo genial.

Responder

Renzo Osorio
Renzo Osorio

Muchas gracias José,

por compartir este tipo de información que nos ayuda a estar informados con los nuevos cambios que se vienen.

Saludos.

Responder

Excelente - Estaré esperando las actualizaciones de este Post.

Responder

No esperes más: al final del post tienes un enlace a las 7 siguientes 😉

www.campusmvp.es/.../...-para-conocerlo-mejor.aspx

Saludos.

Responder

Excelente explicación, hace rato estaba confundida con este tema.

Responder

Paul Cordova
Paul Cordova

¿no sería agradable tener un ámbiente de desarrollo donde pueda programar?
1. Elegir C# o Vb.net, en el que sea mar productivo
2. Diseñar mis interfaces de usuario como en Winforms, y tan complejas como sea necesario.
3. Generar automáticamente mi aplicación hacia la web
4. Ejecute en los principales navegadores, sin tener que hacer ajustes especiales
5. Pueda depurar el código directamente en Visual Studio, mientras ejecuto  en un navegador
6. Use de forma transparente websockets para actualizar al cliente desde el servidor

Existe y se llama Wisej

Puedes ver mas detalles en https://www.wisej.com  
casos reales en https://madewithwisej.com
un demo http://demo.wisej.com/codeproject
mis tutoriales en YT www.youtube.com/playlist
Gracias por tu interés.

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.