Introducción
Como era de esperar, la JSConf 2011 ha sido el escenario escogido para la presentación algunos de los más importantes proyectos Javascript en desarrollo. De entre todos ellos, los que más interés han despertado han sido Angular y, como no podía ser de otro modo, el sorprendete y misteriosoTraceur de Google.
Prtagonistas de la JSConf 2011: Angular y Traceur
Angular es un framework tipo MVC que compila HTML mediante plantillas para construir aplicaciones complejas de un modo extremadamente rápido y sencillo. Aunque plenamente funcional, todavía se encuentra en desarrollo (v1.0) y su API aún es susceptible de cambios a lo largo de los próximas semanas.
Tras ver la presentación y hacer algunas pruebas, hay que reconocer que el sistemas es francamente potente y apunta muy alto.
Traceur es el nuevo proyecto Google cuyo objetivo es servir de vehículo entre las nuevas especificaciones Javascript y los navegadores de hoy.
La idea es ofrecer toda una serie de componentes preconfigurados que permiten hacer uso de algunas de las funciones avanzadas más recientes del lenguaje independientemente de la plataforma. De hecho, muchas de esas nuevas implementaciones solo están presente en los borradores del nuevo estándar y no han sido aún propuestas formalmente por el comité.
La separación del lenguaje: un peligro potencial
Google ha desarrollado este proyecto desde sus laboratorios rodeados del secreto más absoluto. Aunque ya ha sido liberado como Open Source, esa fase inicial ha despertado importantes críticas dentro del sector que ha visto como se progresan las capacidades del lenguaje de forma independiente sin tener en cuenta al comité pertinente.
El peligro potencial de esto radica en que todas estas ramificaciones (forks) que están surgiendo, soportadas únicamente por las meta-bibliotecas que lo envuelven, están restando cohesión al lenguaje original al tiempo que desacreditan las directrices de quienes tienen que crear sus especificaciones. Esto es un problema que no ha pasado desapercibido durante el JSConf y que ha reavivado fantasmas como el del reciente fracaso de la cuarta edición del ECMAScript.
CoffeScript y Brendan Eich
Tal y comenta Ian Elliot, Javascript es actualmente el lenguaje de programación más importante de la actualidad: es el más activo en los repositorios de Github, con un crecimiento fulgurante en cuanto a uso general en desarrollos (incluso más allá de aplicaciones web), presente en todo tipo de dispositivos y renacido gracias a la vuelta del paradigma servidor (NodeJs) y a la potencia de los canales persistentes de comunicación bidireccionales (WebSockets).
En este escenario de creciente exitación, cada nuevo evento es celebrado de forma multitudinaria y son muy numerosos los proyectos que buscan expandir de uno u otro modo las capacidades naturales del lenguaje.
Tal y como observó Andrew Dupont durante su presentación, los recientes cambios en cuanto al estándar, han multiplicado los proyectos en la comunidad que buscan implementar desde ya estas mejoras en el escenario actual; del mismo modo, se produce una retroalimentación inversa donde algunas de las nuevas funcionalidades surgen precisamente de su implementación original en este tipo de proyectos tras demostrar que han resultado útiles.
Es es el caso, entre otros, de CoffeScript.
CoffeScript es un (meta)lenguaje construido por encima de Javascript que pretende ser una capa más de abstracción: la idea es ofrecer un nuevo paquete de funciones y métodos que tras compilar, son reescritos internamente en un Javascript válido para todos los navegadores modernos sin la necesidad de realizar grandes actualizaciones. Estas nuevas funcionalidades tratan de cubrir algunas de las deficiencias naturales como son el manejo de clases, herencias y otros aspectos que los desarrolladores echan en falta (más por desconocimiento que por omisión).
La espectación que levantan estos proyectos es grande y suelen presentarse de forma pública como la evolución natural del lenguaje o el nuevo Javascript. Precisamente en esa línea trasncurrió la ponencia de Jeremy Ashkenas titulada CoffeScript como el próximo Javascript (CoffeScript as a JS/Next).
Y de nuevo, volvemos al problema anterior donde, una iniciativa privada -cerrada-, pretende evolucionar de forma independiente al lenguaje según su propia iniciativa.
La proclama de CoffeScript (y similares) como el próximo Javascript es como mínimo pretenciosa, algo que ha aprovechado Brendan Eich para mostrar algunas de las directrices que hay detrás del proyectoHarmony o ECMA TC39, el cual es en principio la base para el desarrollo de lo que será el ECMAScript 6.
“Un proyecto de estas características, debe ser liberado con antelación; del mismo modo, debería haber una fluída comunicación entre tu departamento de desarrollo y el comité TC39 para informarles de tus intenciones y poder invitar así a otros a participar activamente en el proyecto.”
El futuro del lenguaje visto por su creador
“Los desarrolladores Javascript sienten a menudo preocupación por el futuro, especialmente en cuanto a qué navegadores incluirán las especificaciones TC39. (…) Un lenguaje externo que recubra al original compilándolo no puede ser en ningún caso suficiente: Harmony necesita ser implementado en los motores de forma nativa, incluyendo (e idealmente) a V8″.
La idea básica detrás de estas palabras es la de llegar a un acuerdo entre las directrices del comité, las empresas y la comunidad: con herramientas -bibliotecas- como CoffeScript o Traceur, los desarrolladores pueden empezar a utilizar las nuevas funciones despreocupados del entorno en que serán ejecutados los códigos. Sin embargo, que empresas privadas como Google sean las encargadas de determinar qué implementar y cómo, es un problema potencial cara a la estandarización del lenguaje.
Eich insiste en la necesidad de que los navegadores implementen las últimas revisiones de Harmony lo antes posible con el fin de evitar forks y la cada vez más habitual presencia de funciones y métodos preconfigurados exclusivos (y no estándares) de cada plataforma (por ejemplo, el método __proto__ de Webkit para construir el sistema de herencia prototípica).
Un análisis de las nuevas funciones previstas para la nueva edición del estándar, muestran cambios tanto a nivel sintáctico como estructural. Algunos de los objetivos que Brendan Eich quiere alcanzar con Harmony son los siguientes:
- Mejorar el lenguaje para facilitar la escritura de aplicaciones complejas.
- Mejorar la arquitectura para crear bibliotecas.
- Mejorar la capacidad de debug/test. Si es posible, crear una especificación nativa para pruebas.
- Adoptar los estándares de facto cuando sea posible,
- Mantener el versionado tan simple y lineal como sea posible.
- Ampliar el soporte para objetos
La inclusión de los estándares de facto es algo que la comunidad está demandando y que permitiría en parte reconciliar a la línea más oficial del lenguaje con la implementada en el mundo real.
A este respecto, una de los puntos más interesantes es el de rediseñar la herencia prototípica buscando el modelo presentado por CoffeScript (y su flexible sintaxis con class, super y @). Eich vuelve a reconocer así que se equivocó en su adopción del concepto del prototipo como elemento para articular el lenguaje Javascript: pese a la flexibilidad de éstos, los desarrolladores llevan ya una década pidiendo un sistema de clases más tradicional al modo Java. Finalmente, parece que estas peticiones serán escuchadas y las nuevas especificaciones apuntan a un rediseño integral en cuanto a la creación y manejo de objetos.
Otro aspecto importante que vendrá de la mano de Harmony será el manejo nativo por parte del intérprete de datos binarios (binary data) gracias al cual se conseguirá un acceso portable, eficiente, y estructurado a este tipo de datos así como a interfaces para sistemas externos del tipo XMLHttpRequest, HTML5 File API y WebGL.
Para más información, los requisitos, objetivos y lo que siginifican, podemos visitar la wiki del proyecto.
Una explicación más detallada de mano del propio Brendan la tenemos en la transcripción de su charlaaquí.
Conclusión
El futuro de Javascript queda así algo incierto: si los responsables del comité saben escuchar las demandas de los desarrolladores y las implementan a su debido tiempo, harán innecesarios los numerosos proyectos que han surgido con el objetivo de extender sus capacidades originales. Con ello, además de ganar consistencia, nos reconduciría hacia la consolidación del estándar evitando grandes fiascos como ocurrió en su día con ECMAScript4.
No hay comentarios:
Publicar un comentario