La Web está Obteniendo su Bytecode: WebAssembly. Rendimiento Nativo en el Navegador.

El siguiente paso en la evolución de JavaScript y asm.js es acabar con ambos.

En la búsqueda de JavaScript cada vez más rápido, ha habido un refrán recurrente: ¿por qué utilizar JavaScript?

Los motores de JavaScript han sido un foco importante para los desarrolladores de navegadores durante varios años, y el resultado ha sido las mejoras de rendimiento sustanciales de cada proveedor. La compilación JIT ("just-in-time") convierte código JavaScript en instrucciones que se pueden ejecutar directamente en el procesador. Este avance trajo enormes ganancias de velocidad. Se han añadido nuevos tipos de datos al lenguaje para reducir la sobrecarga al procesar los números y, combinados con asm.js, un subconjunto limitado de alto rendimiento de JavaScript, las aplicaciones que se ejecutan en el navegador pueden lograr un rendimiento comparable al del código nativo.

A pesar de estas mejoras, la pregunta de "¿por qué JavaScript?" permanece. Esto no es sin razón. El uso de JavaScript implica ciertos gastos generales: los navegadores tienen que leer e interpretar un lenguaje basado en texto diseñado para autores humanos, no para máquinas. El diseño de JavaScript en sí tiene características que son subóptimas desde una perspectiva de rendimiento; la forma en que una variable JavaScript puede representar un número, una cadena o un fragmento de HTML significa que un compilador JIT puede no ser capaz de optimizar tan agresivamente como gustaría. La capacidad de modificar el comportamiento incluso de objetos incorporados, como arrays, puede ser similarmente problemáticos.

JavaScript tiene ciertas ventajas importantes: es un entorno de seguridad en un ambiente sandboxed, lo que significa que (con excepción de los errores del navegador) los programas JavaScript no pueden escapar más allá de los límites del navegador para acceder a los datos confidenciales o instalar malware persistente. JavaScript también es independiente del procesador, por lo que los scripts se ejecutarán igual de bien en un PC x86 como lo harán en un teléfono inteligente ARM.

Te puede interesar: ¿Porqué Google prefiere Java como lenguaje de programación frente a Python o PHP?

Sin embargo, hay maneras bien conocidas de proporcionar las ventajas de JavaScript sin esas desventajas percibidas: bytecode runtimes como Java y .NET. A diferencia de los archivos de script, el bytecode representa una representación de bajo nivel y bastante compacta de un programa. Los Bytecodes también tienden a ser mucho más fácil de leer y compilar JIT para las computadoras. Los sistemas Bytecode tienden a mapear de forma limpia las capacidades aritméticas subyacentes del procesador, también; tienden a operar en enteros simples y números de coma flotante, evitando así la complejidad del sistema de objetos de JavaScript.

Como tal, ha existido durante mucho tiempo un grado de presión para utilizar un sistema de bytecode para el navegador. Tanto Microsoft como Sun (ahora Oracle) hicieron esto con .NET y Java, respectivamente, pero estos sistemas dependían de plugins, en lugar de estar integrados en el motor de renderizado del navegador de la forma en que está JavaScript. Los programas JavaScript podrían manipular directamente objetos HTML; los plugins estaban apagados en su propio mundo, aparte de las páginas HTML en las que residían.

Google construyó un par de sistemas para intentar ampliar el navegador para ir más allá de JavaScript. Native Client (NaCl) ejecutó programas x86 (o ARM) en un entorno seguro y Portable Native Client (PNaCl) hizo lo mismo, pero utilizando un tipo de bytecode en lugar de x86 o código ARM. Sin embargo, mientras Google defendía estos enfoques, otros vendedores de navegadores los rechazaban en gran medida. El JavaScript era el denominador común más bajo; era lo único que todos los navegadores tenían que implementar, por lo que se pensó que era mejor hacer JavaScript mejor que intentar inventar un sistema completamente nuevo.

Como JavaScript se hizo más rápido, el navegador también se hizo más capaz. WebGL, por ejemplo, expuso gráficos 3D acelerados de hardware al desarrollador de JavaScript. Las nuevas API, para dar acceso a, por ejemplo, controladores de juegos, cámaras web y micrófonos, han sido desarrolladas, ampliando el alcance de lo que JavaScript puede hacer en el navegador. Simultáneamente, se diseñó una gama de JavaScript-basado-pero-no-realmente-JavaScript. Microsoft creó TypeScript, por ejemplo, que ofrece varias características de lenguaje que Microsoft cree que son útiles para el desarrollo de grandes programas por grandes equipos. Pero los navegadores no tienen que soportar TypeScript: el compilador de TypeScript produce JavaScript normal que puede ejecutarse en cualquier navegador.

Este tipo de uso de gran alcance llevó a Scott Hanselman de Microsoft a apodar a Javascript el "lenguaje ensamblador para el Web", un sentimiento ampliamente compartido por la gente como Brendan Eich, que inventó JavaScript, y Douglas Crockford, que inventó JSON, ampliamente utilizado para el Javascript Basado en datos.

Pero las personas que pedían un código de bytes para el navegador nunca se fueron, y no estaban completamente equivocadas sobre las ventajas de hacerlo. Y ahora van a cumplir su deseo. WebAssembly es un nuevo proyecto en el que trabajan las personas de Mozilla , Microsoft , Google y Apple, para producir un bytecode para la Web.

WebAssembly o WASM para abreviar, se pretende que sea un código de bytes portátil que será eficaz para los navegadores para descargar y cargar, proporcionando un objetivo más eficiente para los compiladores tan simple como JavaScript o incluso asm.js . Como, por ejemplo, el bytecode .NET, las instrucciones wasm operan en tipos de máquinas nativas como enteros de 32 bits, lo que permite una compilación eficiente. También está diseñado para ser extensible, para que sea fácil agregar, digamos, soporte para juegos de instrucciones SIMD como SSE y AVX.

Te puede interesar: Programación Competitiva: ¿ Es Importante en las Grandes Compañías?

WebAssembly incluirá una notación binaria, que generarán los compiladores, y una notación de texto correspondiente, adecuada para su visualización en depuradores o entornos de desarrollo. Los primeros prototipos ya muestran algunas de las ventajas esperadas; la representación binaria es 20 veces más rápida al analizar que el equivalente asm.js .

Las personas detrás de wasm no han olvidado que JavaScript es compatible en todas partes y wasm actualmente no lo es actualmente. Su plan es llenar el hueco con un polyfill; Un script JavaScript que convertirá wasm a asm.js para aquellos navegadores que no tengan soporte nativo de wasm. El navegador interpretará directamente el wasm, o cargará el polyfill y ejecutará el asm.js resultante. El manejo nativo debe ser más rápido, pero el polyfill significa que un desarrollador puede estar seguro de que un programa wasm siempre funcionará.

WASM todavía está en las primeras etapas de desarrollo. No hay ningún organismo de normas formal detrás de él, sólo un grupo informal de la comunidad . Las especificaciones no son completas, y el diseño de alto nivel todavía está siendo decidido. Pero con los cuatro principales fabricantes de motores de navegación trabajando juntos, el futuro del wasm debe ser brillante. Y los escépticos de JavaScript que han estado gritando por un bytecode durante tanto tiempo finalmente obtendrán su deseo.

¿Crees que esto será posible? Empecemos el debate en los comentario.