- Un ingeniero de Google presentó ante el comité oficial de estandarización una propuesta para dividir JavaScript en dos lenguajes
- Propone dividirlo en un núcleo implementado en el motor de ejecución y una variante con más funciones que dependa de herramientas que lo compilen
- La presentación se realizó a principios de este mes en la reunión de Ecma TC39
- TC39 es el comité de Ecma International que desarrolla la especificación de JavaScript, oficialmente ECMAScript
- La presentación estuvo a cargo de Shu-yu Guo, de Google, y las diapositivas fueron elaboradas junto con coautores de Mozilla, Apple, Moddable y Sony
- Shu-yu es especialista en JIT, VM, compiladores y estandarización
- Argumentos de los autores
- Las nuevas funciones del lenguaje casi siempre empeoran la seguridad, y tienen un impacto neutro o negativo en el rendimiento
- La estabilidad a veces también empeora, y la funcionalidad de las aplicaciones solo mejora si los desarrolladores usan las nuevas funciones
- La VM de JavaScript (máquina virtual) ya se ha vuelto extremadamente compleja por la presión por la velocidad, lo que compromete la seguridad. Además, esto se ve especialmente mal cuando las nuevas funciones no se adoptan
- Dado que las fallas de seguridad y el “costo de complejidad” del runtime afectan a miles de millones de usos, mientras que los beneficios en realidad se limitan a los desarrolladores y aplicaciones que aprovechan esa complejidad, la tecnología base de JavaScript debería ser simple
- Aunque participan varias organizaciones, esta iniciativa parece estar impulsada en cierta medida por Google
- Una de las diapositivas incluye la advertencia: “Esta posible solución es la solución preferida por Google y no necesariamente la de otros implementadores”
- Solución propuesta
- No se trata de revertir las funciones existentes, sino de cambiar el enfoque para que, en adelante, la mayoría de las nuevas funciones se implementen en herramientas y no en el motor
- El lenguaje implementado en el motor se llamaría "JS0" y el lenguaje implementado en herramientas se llamaría "JSSugar"
- Es una idea especialmente adecuada para JavaScript, porque muchos desarrolladores en la práctica programan en TypeScript y dependen de compiladores como Babel, Webpack y el compilador de TypeScript
- Si se adopta, las futuras funciones de sintaxis irían a JSSugar, mientras que solo las API y funciones de capacidades irían a JS0
- Los motores compatibles solo tendrían que soportar JS0
- La carga se trasladaría a los implementadores de herramientas para soportar JSSugar
- Como efecto secundario, los implementadores de herramientas tendrían que involucrarse más en el proceso de estandarización y quizá formar un nuevo grupo técnico
- La propuesta ya es polémica
- Hay desarrolladores que piden no otorgar estatus oficial a las herramientas de JavaScript, y muchos desarrolladores de JavaScript quieren depender menos de estas herramientas
- Existe un amplio consenso en priorizar seguridad, rendimiento y estabilidad, pero la idea de hacer que JavaScript dependa de herramientas intermedias no es popular
- Un desarrollador incluso dijo: "RIP Vanilla JS"
Opinión de GN⁺
- Esta propuesta podría traer un gran cambio al ecosistema de desarrollo de JavaScript. Existe preocupación porque los desarrolladores tendrían que depender más de compiladores para usar nuevas funciones de sintaxis
- Sin embargo, el objetivo mismo de reducir la complejidad del motor de ejecución y mejorar la seguridad y el rendimiento es positivo. A largo plazo, podría ayudar a la evolución de JavaScript
- Otro lenguaje que adopta un enfoque similar es Dart. Dart ofrece una sintaxis amigable para desarrolladores, pero se compila a JavaScript para ejecutarse en el navegador
- Al considerar la adopción de esta propuesta, habrá que evaluar cuidadosamente varios factores, como la compatibilidad con el código existente, la experiencia del desarrollador y el soporte de herramientas. También será necesario un proceso que recoja suficientemente la opinión de la comunidad
- Dado que JavaScript es un lenguaje fundamental para el desarrollo web, se espera que continúen las discusiones activas y su evolución
4 comentarios
Parece que quieren agregar una capa más y añadir a esa capa cosas que ayuden a la DX.
Incluso JSX, desde ya, tiene un ecosistema construido de forma que requiere transpilarse, así que me parece una opinión poco realista. Parece que creen que NodeJS lo es todo.
No sé si lo entendí exactamente bien, pero me da una sensación parecida a BOOST en C++. Si la propuesta de Google se aprueba y se integran las bibliotecas existentes en JSSugar, ¿qué entraría ahí? ¿Babel?
Opiniones en Hacker News
La VM HotSpot de Java le dio un gran éxito a otros lenguajes. También tendría sentido que JavaScript apuntara a un lenguaje núcleo de forma similar y que el azúcar sintáctico se precompile
Es mejor enfocarse en WebAssembly. JavaScript debería usarse para scripting y otros lenguajes para aplicaciones más grandes
Como alguien que prefiere VanillaJS, hay descontento con funciones del lenguaje que cambian de manera forzada. Deberían enfocarse en mejorar las API para que las web apps estén al nivel de las apps nativas
Se rechaza la afirmación de que no hay casos de uso para BigInt. Aunque los desarrolladores frontend de Google no lo usen, otros desarrolladores de JS sí lo hacen. Hay que enfocarse en la evolución del lenguaje
JavaScript y Wasm debieron haberse separado. En cambio, hicieron de Wasm un ciudadano de segunda clase sin acceso a las Web API
La solución propuesta no resuelve el problema de fondo y termina haciendo depender todo de las herramientas. JavaScript debería migrar a un lenguaje nuevo para reducir el costo de rendimiento y complejidad
Los problemas surgen por la desconexión entre TC39 y la comunidad de desarrolladores. Las herramientas de TypeScript no se han estandarizado y no hay planes de portarlas a Rust
Se proponen cambios en JavaScript por los problemas de mantenimiento del motor V8 de Google. Los problemas de seguridad y el costo de complejidad afectan a los usuarios. Deberían probar otro lenguaje en lugar de C++