14/11/2017Artículo original
Hace 6 años Erik Meijer y yo hablábamos de cómo JavaScript es/era una especie de lenguaje ensamblador. Se convirtió en un debate/discusión interesante (algunas personas realmente no compraban esta idea) pero yo seguí adelante con la idea. Actualmente el mundo de WebAssembly va viento en popa y es compatible con Chrome, Firefox, y está en desarrollo en Edge, Opera y Safari.
Hoy, en 2017, WebAssembly es algo grande y puedes aprender sobre ello en http://webassembly.org. Incluso hice un podcast sobre WebAssembly con el compañero de Mozilla David Bryant (realmente deberías ver mi podcast, estoy muy orgulloso de él. Es bueno).
La imagen anterior es de la presentación de Steve Sanderson en el NDC. Está programando la clásica aplicación de lado cliente con JavaScript para llevar una lista de tareas (ToDo)… con la salvedad de que está escribiendo el código en C#.
¿Qué es WebAssembly?
“Webassembly o WASM es un formato bytecode de bajo nivel para secuencias de comandos en el lado del cliente (el navegador), evolucionado desde JavaScript”. Puedes compilar fácilmente a WebAssembly desde C y C++ hoy en día… y más lenguajes de programación se están subiendo al carro para incluir WebAssembly como objetivo de compilación cada día.
Puesto que trabajo en .NET de código abierto y como .NET Core 2.0 es multi-plataforma con una versión inminente, merece la pena explorar dónde encaja WebAssembly en el mundo .NET.
He aquí algunos proyectos que he identificado que ayudan a unir el mundo de .Net con el mundo de WebAssembly. Creo que esto va a ser la bomba en los próximos 18 meses.
A pesar de su nombre tan general, este proyecto OSS está destinado a consumir archivos binarios WASM y ejecutarlos desde dentro de los ensamblados de .NET. Para ser claros, esto no compila lenguajes de .NET (C#, VB.NET, F #) a WebAssembly, esto es para usar WebAssembly como si fuera cualquier otra pieza de código compilado reutilizable. ¿Tienes un archivo WASM que realmente quieres llamar desde. NET? Esto es para eso.
Curiosamente, este proyecto no lanza un motor de JavaScript V8 o Chakra para ejecutar WASM, lo que hace es leer el bytecode y convertirlo a .NET a través de System.Reflection.Emit. ¡Muy curioso!
Una de las grandes cosas que ocurren en el ecosistema .NET es que existe más de un “.NET” en la actualidad. En el pasado, .NET era una cosa que instalabas en Windows y que por regla general te daba miedo. Hoy, .NET 4.x+ está instalado prácticamente en todas las máquinas Windows del mundo, y tenemos .NET Core que se ejecuta en Docker, en Mac, en Windows, en una docena de sistemas Linux… incluso en Raspberry Pi, y Mono es otra instancia de .NET que permite ejecutar código .NET en docenas de otras plataformas. Existen múltiples “instancias de .NET” en desarrollo activo por ahí.
El proyecto MONO tiene dos prototipos utilizando MONO y WebAssembly.
Así que eso es un Hola Mundo totalmente compilado estáticamente… Es todo Mono y tu aplicación metida en WebAssembly. Tienen otro prototipo con una perspectiva diferente:
Aquí tienen mucho de Mono ejecutándose en el WebAssembly, pero tu código IL se interpreta. ¡Una de las maravillas de la informática -hay más de una forma de hacer las cosas, y a menudo cada una es impresionante a su manera!
Con una idea similar al segundo prototipo del proyecto Mono, Steve Sanderson tomó otra “instancia de .NET”, el proyecto Open Source de 6 años de antigüedad DotNetAnywhere (DNA), y lo compiló en WebAssembly. DNA era un runtime interpretado de .NET escrito en C portable. Toma el estándar IL o CIL (lenguaje intermedio común) y lo ejecuta “en dispositivos con recursos limitados en los que no es posible ejecutar un runtime completo de .NET (por ejemplo, Mono)”. Ingenioso, ¿no? ¿Qué “dispositivo con limitaciones de recursos tenemos seis años después?” Vaya, es la pequeña máquina virtual -la MV JavaScript que tu navegador ya tiene, ahora accionado por un formato bytecode estándar llamado WebAssembly.
Para comprobar el concepto, Steve compila DotNetAnywhere a WASM pero luego lo lleva más lejos. Ha combinado modelos de programación estándar que vemos en la web con cosas como Angular, Knockoutjs, o Ember excepto que en lugar de programar la UI de aplicaciones web en JavaScript, lo haces en C#- un lenguaje de programación .NET.
Aquí, en el medio de algunos fragmentos de Razor (básicamente HTML con C# inline), hace lo que parece una llamada a un backend. Esto es código en C#, pero se ejecuta como WASM en el lado del cliente dentro de una aplicación de Blazor:
@functions { WeatherForecast[] forecasts; override protected async Task InitAsync() { using (var client = new HttpClient()) { var json = await client.GetStringAsync(AbsoluteUrl("/api/SampleData/WeatherForecasts")); forecasts = JsonUtil.Deserialize<WeatherForecast[]>(json); } }}Esto permitiría a un programador de .NET utilizar los mismos modelos de datos en el cliente y el servidor -muy parecido a un JavaScript bien factorizado hoy en día-, así como el uso de otras bibliotecas .NET con las que podrían estar familiarizados o sentirse cómodos.
¿Por qué hacer esta locura? “Para ver cómo de bien podría funcionar un framework semejante y comprobar cuánto le importaría a la gente.” ¿Hasta dónde puede llegar esto? David Fowler ya tiene la depuración funcionando (repito de nuevo, TODO esto son prototipos) en Visual Studio Code. No hace falta que creas mi palabra, mira el vídeo en el que Steve presenta el concepto en la Conferencia NDC.
Blazor como prototipo ya tiene a muchas personas entusiasmadas, y recientemente se ha celebrado un hackthon de Blazer del que han salido unas muestras interesantes, incluyendo una aplicación completa.
¿Otras posibilidades?
Existen muchos otros proyectos que están compilando o transpilando cosas a JavaScript. ¿Se pueden modificar para soportar WebAssembly? Puedes coger F# y compilarlo a JavaScript con el Fable Project de F#, y algunas personas han preguntado acerca de WebAssembly.
En este punto está claro que todo el mundo está haciendo prototipos, hackeando cosas y disfrutando.
¿Qué opinas TÚ sobre WebAssembly?
