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 misterioso Traceur 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 proyecto Harmony 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 charla aquí.
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.
A mi entender, la aparición de Traceur o de Coffescript (este último hace ya varios años) es algo natural que sucede cuando una tecnología no evoluciona a los tiempos que la industria lo requiere.
Estas herramientas (y el hecho del intereses de los desarrolladores y empresas por usarlas) es un llamado de atención, es como decir: – Hey, nuestros tiempos son otros, queremos evolucionar más rápido. –
Pero el asunto no solo sucede en el campo de JS, también sucede con CSS (ej: Sass, Less, Compass…), HTML (ej: funcionalidades HTML5 experimentales aún no estandarizadas) hasta con otras cosas: SPDY como reemplazo al protocolo HTTP, Node.Js y su API no-bloqueante, etc…
Esta claro que hacer evolucionar a una tecnología no es algo que se puede hacer de un día para el otro, pero la salida de este tipo de proyectos hace que se ponga en discusión la forma de hacerlo.
Saludos
Yo no estoy muy de acuerdo que hayan iniciativas fuera del estándar, quizás sí que pueda parecer en un principio una necesidad, pero a lo largo con el tiempo se vuelven unos escollos que arrastran consigo muchos problemas, el caso más claro es internet explorer del que microsoft se paso por el forro cualquier especificación de la W3C y que todavía arrastramos los problemas
Perdona, ¿podrías especificar dónde Breanda Eich «vuelve a reconocer así que se equivocó en su adopción del concepto del prototipo» [sic]?
No es un secreto que Brendan ha confesado activa y pasivamente que su adopción del sistema prototípico fue un error. Cuando diseñó el lenguaje, allá por 1995, la programación con objetos estaba en auge. Era el mismo año que nacía Java y su dependencia de clases. JavaScript, sin embargo optó por un concepto nuevo y radical: los prototipos.
Con el tiempo, los desarrolladores no llegaron nunca a entender la filosofía tras este nuevo concepto y Brendan lo sabe:
«We could renounce classes in order to remain future-proof, but JS developers are crying out for sweet and (more important) foolproof syntax to make prototype-based single-inheritance class-like abstractions. We should pave this cowpath now.»
Recientemente, tanto en las charlas privadas con colegas como en sus conferencias, está dejando claro que el camino de Harmony es, precisamente, harmonizar todas las especificaciones del estándar y llegar a un consenso con los desarrolladores. Y, uno de los puntos críticos aquí, es la adopción de un esquema de objetos tradicioal.
Brendan reconoció en abril de este año, 2011, con motivo de una presentación de Mozilla (no tengo enlace) que llevaba años tratando de explicar a los desarrolladores «cómo demonios funcionaban los prototipos» y que se lamentaba de su adopción años atrás. De hecho, reconocía el valor de bibliotecas como jQuery y CoffeeScript en su intento de estandarizar los conceptos de herencia prototípica con una sintaxis ‘tradicional’ de clases:
«At this point in my talk, I advocated strongly for standardizing prototypal inheritance a la CoffeeScript’s class, super, and @ syntactic sugar.»
Saludos.
La afirmación
es un poco exagerada, ¿no te parece?
Por otra parte
Esto vas más allá de extender o superar. Hay muchos desarrolladores que disfrutan creando nuevos lenguajes y hacer que «compilen» generando JavaScript hace posible que dichos lenguajes sean fácilmente visibles en la web. Uno de estos proyectos ha adquirido masa crítica, sobre todo en el ámbito de los desarrolladores Ruby, pero esto no implica que haya que ir dando bandazos en la especificación no vaya a ser que el lenguaje de programación común a todos los navegadores sea destronado.
Finalmente catalogar a la versión 4 en la categoría de los grandes fiascos está un poco fuera de lugar. Simplemente no se llegó a un acuerdo y no vio la luz.
Las conclusiones de tu artículo me parecen «sensacionalistas».
Por futuro incierto no entendemos que vaya a desaparecer, sino que no sabemos con exactitud hacia dónde va: tenemos por un lado a un comité que marca una directrices; por otro, a la comunidad con sus propias demandas. En medio, tenemos a una capa de desarrolladores que implementan esas mejoras por su cuenta a través de sub(meta)lenguajes…
En ningún momento quiero dar a entender que el futuro de Javascript está entredicho. Nada más lejos de la realidad: es el lenguaje con mayor proyección a día de hoy.
En cuanto al ES4, trabajar en un estándar varios años para finalmente desecharlo por desacuerdos entre los comités es, a mi entender, un fracaso que debería evitarse en lo sucesivo.
No obstante, es sólo mi opinión 😉
Saludos.
Siendo precisos CoffeeScript no es un meta lenguaje. Es un lenguaje convencional que puede traducirse a JavaScript.