Un ingeniero de Google planteó dividir el lenguaje en dos variantes, una fundamental y otra avanzada. Esta propuesta, que ha generado opiniones encontradas en la comunidad programadora, sugiere un cambio radical en la estructura de JavaScript con el fin de mejorar su seguridad y rendimiento.
A principios de este mes, durante una reunión del comité TC39, que supervisa la evolución del estándar ECMAScript, Shu-yu Guo, ingeniero especializado en optimización de código en Google, presentó la idea junto a expertos de empresas como Mozilla, Apple, Sony y Moddable. Su propuesta aboga por simplificar el núcleo de JavaScript —llamado provisionalmente "JS0"—, mientras que las características avanzadas o "azucaradas" se implementarían en una variante separada, denominada "JSSugar", según informó DevClass. Esta división permitiría que el motor de ejecución solo soporte lo esencial, y que las funciones avanzadas queden a cargo de herramientas de compilación.
De acuerdo a los autores de la propuesta, la introducción de nuevas características en JavaScript ha sido en gran medida perjudicial. Argumentan que muchas de estas funciones no han sido ampliamente adoptadas y que, en su mayoría, incrementan la complejidad y las vulnerabilidades sin beneficios significativos. Un ejemplo mencionado es la funcionalidad BigInt, que permite manejar números de gran tamaño, pero cuya adopción ha sido escasa.
Para los desarrolladores de motores de JavaScript, esta complejidad adicional representa un costo de seguridad y rendimiento. Cada nueva característica demanda tiempo y esfuerzo en su implementación y mantenimiento, lo que no siempre se traduce en mejoras significativas para la mayoría de los usuarios. De esta manera, el enfoque de dividir JavaScript en dos, manteniendo un núcleo básico y delegando las características avanzadas a herramientas de terceros, busca reducir la carga y los riesgos asociados con los motores de JavaScript.
En este esquema, JS0 representaría el núcleo fundamental de JavaScript que cada motor de ejecución debe implementar, manteniéndolo simple y enfocado en lo esencial. Por otro lado, JSSugar incluiría las características avanzadas y más complejas que se compilarían en JS0 mediante herramientas como Babel o Webpack, algo que ya ocurre con TypeScript, que depende de herramientas para transformarse en JavaScript.
Si esta propuesta se implementa, los desarrolladores podrían beneficiarse de un motor JavaScript más seguro y eficiente, mientras que las herramientas de compilación se ocuparían de las funciones avanzadas. Sin embargo, esto también significaría que la dependencia de herramientas externas sería mayor, un cambio que ha generado inquietud en la comunidad.
La idea de Google ha generado una fuerte controversia. Mientras algunos desarrolladores apoyan el enfoque de mejorar la seguridad y el rendimiento mediante la simplificación, otros consideran que aumentar la dependencia de herramientas externas traería complicaciones adicionales. "Por favor, no oficialicen el uso de estas herramientas de JavaScript", comentó un desarrollador, destacando el deseo de mantener la autonomía de escribir JavaScript sin intermediarios.
Por otro lado, voces de la comunidad expresaron preocupación sobre el fin de “Vanilla JS” —la forma pura de JavaScript sin depender de librerías o compiladores—, ya que la propuesta de Google implicaría que cada vez más funcionalidades quedarían fuera del alcance de este enfoque directo.
El debate está abierto y el futuro de JavaScript, tal como lo conocemos, podría tomar un giro inesperado si esta propuesta sigue adelante. Aunque el comité TC39 aún debe evaluar la viabilidad de esta propuesta, está claro que cualquier decisión tendrá un impacto profundo en el desarrollo web y en cómo los programadores se relacionan con JavaScript.
Este posible rediseño del lenguaje de scripting más popular del mundo plantea una pregunta fundamental: ¿debe JavaScript mantenerse simple y seguro, o debe continuar evolucionando y adaptándose a las crecientes demandas de funcionalidad avanzada, aunque eso signifique aumentar su complejidad?
Comments