Google Dart y el estado actual de Javascript
No recuerdo ya cuanto llevo exactamente trabajando con Javascript pero siempre voy a tener presente el 2011 como el año en el que la gran mayoría de los desarrolladores web comenzaron a ver el lenguaje con respecto y asímismo a estudiarlo. Es interesante ver cuanto han cambiado las cosas estos últimos dos años. Ya vemos aplicaciones muy complejas que corren casi que en su totalidad en el navegador, ya hasta he escuchado que llaman a los navegadores: “Nuevas plataformas de juegos” lo cual suena bastante emocionante teniendo en cuenta que hasta hace 4 años si hacías que un formulario se enviara asincronamente al servidor te consideraban un dios.
Sí, los tiempos han cambiado, la tercera edición de ECMAScript fue liberada en 1999, la quinta recomendación actual) en el 2009-2010 y es gratificante saber que la siguiente versión se está desarrollando, lo cuál significa que se está prestando bastante atención a potencializar el lenguaje.
Las consecuencias de un mal diseño
Como muchas personas amo Javascript y me siento a gusto con lo que puedo hacer con él, pero seamos sinceros, es un lenguaje terriblemente mal diseñado. Tiene problemas que son muy difíciles de solucionar o “cubrir”. Durante años los desarrolladores se han quejado de su tipado, ausencia de clases, paradigma de prototipos, velocidad y así un largo etcétera. Con el desarrollo del nuevo estándar se planea solucionar varios de estos problemas pero se sigue negando a JS la capacidad de tener clases así que se están pensando alternativas que a mi manera de ver las cosas complejizan la curva de aprendizaje y la legibilidad. Esto al parecer lo ha visto Google así que para facilitarle la vida a la comunidad de desarrolladores decidió diseñar Dart que tiene la posibilidad de correr sobre una máquina virtual en Chrome (aún no implementada) o compilar el código directamente a Javascript.
Dart propone una sintaxis muy similar a Java. Incluye clases, interfaces, tipos personalizados, acceso al DOM a través del API estándar y otros comportamientos estrictos como la eliminación de la coerción de cualquier objeto a un valor booleano. Esto es, que lo único que se evalúa como verdadero es el valor booleano true. Dart también incluye interfaces como Iterable y Comparable, que para quienes vienen de lenguajes como Java les serían muy útiles.
Sí, existen otras alternativas
Para muchos desarrolladores, Javascript es ya un lenguaje complicado de entender pues no sigue los estereotipos y sintáxis que se podría considerar dentro de lo normal para un lenguaje de programación orientado a objetos. Débido a esto, se han dado a conocer varios pseudolenguajes para facilitarnos la vida.
El proyecto más conocido es CoffeeScript que si no estoy mal fue desarrollado por un miembro de la comunidad de Ruby. Al ver la sintaxis es difícil no darse cuenta que lo que se quiere es escribir poco y hacer más (cité el tagline de jQuery sin querer). A CoffeeScript se le ha trabajado duro y ha mejorado bastante con repecto a las primeras versiones. Ha sido fuertemente criticado por la comunidad de Javascript por su bajo o nulo soporte de funcionalidades existentes en versiones modernas y no estandares de Javascript como los generadores de expresiones o el modo estricto de ES5. Personalmente, no me gusta CoffeScript pues me gusta tener control sobre el lenguaje que estoy escribiendo, además de que tampoco me agrada el código que genera al compilarlo a Javascript.
Javascript++ es un proyecto que mejora las capacidades de Javascript soportando Clases, sistema de tipos de datos y otras funcionalidades sin sacrificar el hecho que la sintáxis de Javascript esté basada en C.
Una alternativa poco conocido y que fue lanzada en el último JSConf es Traceur Compiler. Lo que quisieron hacer con esto fue traer a hoy todas las funcionalidades y maravillas que se están pensando para Javascript en el futuro. Clases, modulos, generadores, valor de parámetros por defecto y una larga lista de características que han sido propuestas como estándar. Es una propuesta muy bonita y también permite compilar a Javascript.
Aplicación en proyectos reales
Considero que los proyectos en los que de verdad se debe pensar al momento de utilizar un pseudolenguaje es a los robustos. No es lo mismo un script para varios formularios o slideshows que escribir toda una aplicación al lado del cliente. Considero que tanto Dart, CoffeeScript y demás alternativas generan un lio enorme en tiempo de depuración ya que el código que en realidad se está ejecutando es compilado y reemplaza los identificadores que se escribieron en el código fuente con un diccionario que sólo el compilador conoce. Así que teniendo en cuenta los grandes bloques de código que generan estos compiladores, es fácil calcular lo complicado que será encontrar un error.
En el caso especifico de Dart, éste despliega todo su framework a Javascript para cualquier cosa que hagamos, así sea sólo una línea. Teniendo en cuenta la cantidad de características que incluye es más que natural que deba crear todo un espacio de trabajo para evitar la violación de sus reglas. Esto termina en scripts más grandes de lo esperado y por consiguiente depuración y ejecución más lenta que si lo hicieramos directamente en Javascript.
¿Qué pasa entonces con HTML5?
No pasa absolutamente nada. La W3C es la encargada de definir las recomendaciones para el API de cada nueva característica de HTML5 pero nunca dice que debe ser Javascript. Este API debe seguir intacto independientemente de la implementación. Siendo así, desde Dart se debería poder seguir usando los métodos de acceso al DOM, canvas, video, SVG, LocalStorage y demás tal como ya las conocemos.
Conclusiones
Google siempre quiere ser el super héreo que nos quiere hacer la vida fácil pero sin darse cuenta lo que a veces hace es complicarla un poco más. No les bastó con tener un proyecto ya muy adoptado como lo es GWT así que al no gustarles lo que les ofrecía Javascript decidieron diseñar su propio lenguaje. Tal vez ahora siga rediseñar Python o algo similar. Ahora que lo pienso, a mi no me gusta el sistema de transporte mi ciudad así que pensaré en diseñar uno nuevo y tal vez también quiera un cálculo más sencillo pues la matemática que tenemos es algo complicada de entender. Tal vez todos deberíamos diseñar nuestras propias cosas cuando algo de lo existente no nos guste.
| Posted in Javascript | 3 Comments »