Quienes estuvieron presentes en el panorama del programador durante los años 2015-2016, probablemente recuerdan el alboroto que generó la llegada de WebAssembly a los navegadores.

El único lugar donde lo habíamos visto ser usado era en el demo Tanks! que sacó Unity, y aún así todos afirmabamos que WASM sería el futuro.

Definitivamente no soy nadie para afirmar lo opuesto, sin embargo siento que los resultados que hemos visto están lejos de poder ser considerados como verdaderamente exitosos, y ciertamente no parece que el uso de WASM incrementará de manera considerable en el futuro próximo (no niego que a un plazo mayor pueda volverse mucho más popular).

Durante el 2018 recuerdo haber hecho mi primer intento por programar en WASM, sin embargo las herramientas disponibles para programadores se limitaban a WebAssembly Studio en una etapa muy temprana. Dada la poca información al respecto y mi poca experiencia en programación, no logré avanzar muy lejos.

Hace un par de semanas quize hacer nuevamente el intento de programar algo en WASM. No necesariamente algo complejo, pero por lo menos ver cómo podría resolver un problema pequeño hoy en día queriendo usar WASM.

Lo más sensato es evitar WASM en la medida de lo posible, y solo recurrir a él cuando nos provea ventajas significativas. Personalmente opino que son mínimos los casos en que eso sucede. Las personas con las que he hablado sobre temas de web sabrán que tengo opiniones muy fuertes en contra de querer utilizar el navegador como un sistema operativo y portar todo a la web (tendencia muy fuerte en estos últimos años). Está de más decir que si deberíamos evitar usar el navegador como nuestra plataforma principal, es incluso peor idea querer desarrollar procesos intensos en recursos que se ejecuten en el navegador (las razones me parecen obvias pero al parecer muchos desarrolladores web las olvidan, de cualquier manera, no es un rant que quiera hacer en este post).

Pero de cualquier manera, no puedo darme el lujo de desactualizarme. Y es por eso que voy a implementar algo en WASM sin razón de ser. Uno de los proyectos que más me gusta replicar cuando aprendo un nuevo lenguaje de programación es crear un intérprete: necesitamos manejar arreglos, memoria, cadenas, etc. Es suficientemente complejo para darte una buena idea de la experiencia con el lenguaje. Además, procuro hacerlo con algún lenguaje esotérico sencillo, no quiero trabajar 6 meses y al final dejar el proyecto por la complejidad de la tarea.

Mi experiencia

En esta ocasión, me pareció una perfecta opción desarrollar un intérprete para el lenguaje Smallfuck. Esencialmente es una versión de el popular Brainfuck pero sin los comandos de I/O, y que funciona sobre bits, por lo tanto no tenemos los comandos de incremento y decremento, solo un comando para voltear bits.

Y eso es lo que hice. En realidad no trabajé con WASM directamente, así como evitamos utilizar ensamblador. Yo utilicé AssemblyScript, que es un lenguaje con sintaxis similar a TypeScript, pero que compila a WASM. Personalmente sentí que el lenguaje aún no tiene una gran madurez. Han habido avances importantes, pero la documentación es en algunos casos deficiente, e incluso contradictoria en algunos aspectos.

No pretendo quejarme de AssemblyScript, y de hecho me gustaría aprovechar la ocasión para agradecer a la comunidad en Discord que fue muy amable y pronta en contestar. Ciertamente están haciendo un trabajo extraordinario al acercar WASM a los desarrolladores web a través de AssemblyScript, a diferencia de otras herramientas que suelen ser más inaccesibles para los programadores acostumbrados a lenguajes de un más alto nivel. Existen otras alternativas para compilar código en C/C++, Rust o Go a WASM.

No obstante, no consideraría utilizar el lenguaje para algo serio, por lo menos durante los próximos 2 a 3 años. Eventualmente tal vez volveré a darle una oportunidad para ver cuánto ha mejorado.

Como punto de referencia para otras personas que lean esto y quieran intentar programar algo por su cuenta, algunas de las características que me dieron problemas son:

  • Enumeraciones.
  • Interfaz JavaScript - WASM:
    • Arreglos.
    • Strings.
    • Objetos.

En general los problemas eran de documentación más que del lenguaje, pero igualmente es algo que debería mejorar antes de considerar el lenguaje para desarrollos serios.

¿Tiene futuro?

Es difícil visualizar que será de las tecnologías web dentro de 10 años. Estoy seguro de que nadie hace 10 años se habría imaginado la web como es hoy en día. Es por eso, y por la tendencia a migrar todo a la web, que no descarto la idea de que en el futuro WASM sea sumamente importante.

Sin embargo, desde mi punto de vista, WASM no tendrá muchos casos de uso justificados durante los próximos años (tal vez ¿5 años?).

De cualquier manera, en muchos casos la tendencia de la tecnología se mueve en función de las herramientas desarrolladas, y no al revés. Por lo mismo, si el ecosistema de WebAssembly mejora significativamente, podríamos comenzar a ver más situaciones en que los programadores lo incorporan en sus productos.

A mi proyecto de WebAssembly le puse una interfaz desarrollada en Preact, y quedó una página web muy bonita desde la cuál puedes ejecutar y visualizar tu código en WASM. Puedes ver una demo dando click aquí, y el repositorio con mi código se encuentra en GitHub.