por

Google le dice adios a Native Client y apuesta por WebAssembly

Google acaba de anunciar que Chrome ya no admite código nativo en forma de PNaCl. En su lugar seguirá el ejemplo de los otros fabricantes de navegadores y se basará en WebAssembly para obtener un código rápido. En pocas palabras, WebAssembly ganó.

Una aplicación web nativa es cualquier cosa que se compila con el código máquina nativo del sistema en el que se está ejecutando: no hay máquinas virtuales o código de bytes y no hay intérpretes. Por supuesto, esta definición es muy vaga porque la línea entre un intérprete y un compilador just-in-time es muy fina. Sea cual sea la definición, una aplicación nativa es la que se ejecuta rápidamente – lo más rápido posible – de ser posible directamente en el hardware. Los navegadores ejecutan JavaScript que ha mejorado en velocidad a lo largo de los años, pero sigue siendo mucho más lento que el código nativo. Para permitir que Chrome ejecute aplicaciones nativas, en el 2011 Google anunció NaCl (Native Client). La idea era que el código compilado se pudiera ejecutar en un sandbox proporcionado por Chrome. Se permitió a dichos programas “nativos” ejecutar en el navegador a toda velocidad y Google lo probó lanzando algunos juegos.

A los programadores que les gustó realmente y había inicialmente un mucho entusiasmo en esta plataforma. Entonces el gran problema se hizo evidente. NaCl era una característica exclusiva de Chrome y parecía improbable que otro navegador adoptara dicha tecnología. Una versión mejorada del NaCl fue lanzada en 2013, PNaCl. Esta versión usaba un código intermedio portátil que permitía que las aplicaciones nativas funcionaran en un navegador que trabajaba en un hardware muy diverso.

Incluso los programadores que pensaban que PNaCl era bueno, o al menos una buena oportunidad de obtener sus programas C/C ++ en la web, no podían evitar llegar a la conclusión de que sus proyectos iban a ser etiquetados como: “Sólo funciona en Chrome”.

Otros fabricantes de navegadores, Mozilla en particular, expresaron la opinión de que el código nativo en el navegador era un gran error y un caso de pensamiento pasado de moda. El futuro era HTML5 y tecnologías similares. Como resultado el apoyo para PNaCl de los programadores comenzó a desaparecer. Luego apareció asm.js y subsecuentemente WebAssembly – ambos diseñados para hacer que JavaScript fuera más rápido. En este punto, incluso Google debe haber comenzado a pensar que PNaCl no era tan buena idea.

El año pasado el equipo de PNaCl se dispersó, pero el proyecto continuó como uno de fuente abierta. Ahora tenemos la palabra definitiva de que el PNaCl está muerto en lo que se refiere a Google:

Eliminaremos el soporte para PNaCl en el primer trimestre de 2018 en todas partes, excepto en Chrome Apps y Extensiones. Creemos que el ecosistema alrededor de WebAssembly hace que se ajuste mejor para las aplicaciones web de alto rendimiento nuevas y existentes y que el uso de PNaCl es suficientemente bajo como para justificar la decomisión del mismo.

¿Fue WebAssembly quien mató a PNaCl?

El problema es realmente confuso, ya que PNaCl todavía va a ser compatible con ChromeOS. Esto se debe a que proporciona la única forma de ejecutar código nativo en Chromebooks. Esta no es una buena situación para Google y es probable que también este soporte quede obsoleto en un futuro no muy lejano. Después de todo, quién va a pasar el tiempo trabajando en una aplicación PNaCl para ChromeOS, considerando que la tecnología ya no es parte de Chrome.

Google ha preparado algunas ayudas para la migración a WebAssembly, pero esencialmente todo lo que se debe hacer es recompilar el código C/C++ a WebAssembly después de cambiar todas llamada PPAPI a las API web estándar. Obviamente habrán tecnologías que WebAssembly no va a soportar un tiempo, si es que alguna vez llega a soportarlas.

El anuncio anima de esta forma a los programadores a pasar sus aplicaciones a WebAssembly:

Con el lanzamiento de WebAssembly, la plataforma web ha ganado una base para una nueva generación de aplicaciones web rápidas e inmersivas que se ejecutan en cualquier navegador. ¡Estamos emocionados de ver lo que los desarrolladores crean a continuación!

Muchos desarrolladores comentan que migrar a cualquier tecnología basada en JavaScript no es para ellos. Algunos dan razones racionales, como que WebAssembly es demasiado lento, pero sobre todo hay una profunda aversión de al lenguaje de programación JavaScript y por lo tanto cualquier cosa basada en el. El problema más grande que tiene WebAssembly es que sigue siendo inmaduro y tomará tiempo para que se desarrolle hasta el punto en que es iguale a PNaCl, pero por ahora Google está a bordo, deberíamos ver esto como un progreso hacia un lenguaje cross-browser viable que está más cerca a velocidades de ejecución nativas.