El pasado 11 de octubre, en la conferencia GOTO Aarhus, los ingenieros de Google Lars Bak y Gilad Bracha presentaron DART, el nuevo lenguaje de programación creado por Google.
A pesar de la avalancha de artículos en multitud de publicaciones -incluida, por increíble que parezca, prensa nacional– creo que aún existe mucha confusión sobre que es realmente DART y cual es el objetivo final de la compañía de Mountain View.
¿Alguien se ha parado a pensar la ingente cantidad de tiempo, dinero y recursos que se necesita para crear un nuevo lenguaje con el ambicioso objetivo de convertirlo en la nueva lingua franca del desarrollo web? ¿Por qué Google se mete en este jardín? Deberíamos comenzar leyendo este correo interno donde se pueden entrever algunas respuestas.
Los hechos
- Google encuentra errores fundamentales en JavaScript que suponen un incremento exponencial de la dificultad para crear aplicaciones web complejas. Por ejemplo, que sólo exista un tipo primitivo Number, en vez de uno específico para números enteros y otro para decimales.
- Ante este problema, los ingenieros proponen dos soluciones:
- Apoyar una evolución incremental del lenguaje con compatibilidad hacía atrás (proyecto Harmony)
- Desarrollar un nuevo lenguaje desde cero que conserve la naturaleza dinámica de JavaScript, pero tenga un mejor rendimiento y para el que sea más fácil crear herramientas para grandes proyectos (proyecto Dash, finalmente renombrado DART)
- La primera solución la más sencilla, pero también la menos óptima. La segunda opción es mucho más complicada de llevar a cabo, porque implica convencer a terceros, los fabricantes de navegadores, para que implementen de forma nativa el lenguaje. Por eso, DART debe nacer, además de con una máquina virtual que sea capaz de interpretarlo, con un compilador que permita transformarlo en JavaScript que se ejecute en aquellos navegadores que no lo soporten. Casi nada.
Las especulaciones
Pero… ¿Por qué le importa tanto JavaScript a Google? Porque, [highlight]las mismas características que permitieron que el lenguaje se extendiera, suponen un verdadero quebradero de cabeza para proyectos de gran tamaño[/highlight]. Probablemente, no los que desarrollamos el común de los mortales, pero si los que afrontan grandes corporaciones como… oh si, Google.
[quote]¿Alguien se ha parado a pensar la ingente cantidad de tiempo, dinero y recursos que se necesita para crear un nuevo lenguaje con el ambicioso objetivo de convertirlo en la nueva lingua franca del desarrollo web?[/quote]
Vale. A Google, JavaScript se le queda pequeño para el tipo de proyectos en los que esta metido, pero ¿No tenía GWT para resolver ese problema?
GWT es un toolkit que permite desarrollar en Java, detectar errores en tiempo de compilación y generar JavaScript compatible para todos los navegadores como resultado de dicha compilación. Entonces ¿Por qué desarrollar DART? Quizás por ese pequeño detalle de que GWT es un toolkit Java y quizás -insisto de nuevo en el carácter de suposición, no de afirmación digna de gurú mesiánico– [highlight]Google tiene un objetivo mucho más ambicioso que la comunidad Java: los desarrolladores de otros lenguajes de servidor y, sobre todo, los desarrolladores de front-end que sólo trabajan con HTML, CSS y JavaScript[/highlight].
Y, si es cierto que Google cree que el futuro es HTML5 y que el uso de dicho lenguaje más JavaScript -perdón, DART– es el marco de trabajo ideal para desarrollar más fácilmente sus próximos GMail, Docs o Calendar, no sólo para todos los navegadores convencionales, sino para dispositivos móviles -la sombra de iOS es alargada- a la compañía le interesa que haya una rápida y calurosa adopción por una masa crítica de desarrolladores que obliguen a los fabricantes a implementar DART de forma nativa.
La Conclusión
¿Debemos ponernos a aprender DART como si no hubiera mañana? ¿Nos pasamos al CoffeScript sin mirar atrás? ¿Será Harmony la piedra filosofal? NO TENGO NI IDEA. Yo no soy un gurú, pero lo que si se es que, hoy por hoy, lo que funciona en todos nuestros navegadores es pura y simplemente JavaScript -en concreto la versión ECMAScript 3– y que en mi escritorio hay un libro de más de 1.000 páginas llamado «JavaScript. The Definitive Guide» que me gustaría tirarle a más de uno a la cabeza para ver, si de una vez por todas, se ponen de acuerdo y nos dejan tranquilos a los que no queremos crear el lenguaje definitivo para el desarrollo front-end, sino simplemente aplicaciones que, a ser posible, funcionen en todos los lados.