Para los que no lo saben aún, Google está a punto de lanzar hoy browser propio desarrollado casi desde cero: Google Chrome, basado en el motor WebKit que usa Opera, y el proyecto quedará publicado como open source.
Como no podía ser de otra manera, el Maestro se ha hecho eco de la noticia, y leyendo sus comentarios retomo una idea que me viene rondando hace rato:
En poco tiempo el lenguaje de desarrollo principal será Javascript.
Lo mío no es ninguna iluminación; ya lo comentó más extensamente el inefable Steve Yegge, y mucha gente más. Y de hecho no es futurología; ya está sucediendo.
¿Cómo un lenguaje famoso por sus limitaciones y complejidades ha llegado tan lejos? Creo que básicamente porque el lenguaje mismo nunca fue el problema, sino cuestiones de contexto. Los culpables principales de la mala de Javascript son los browsers, creo.
Problema 1 - Incompatibilidades
Los mayores problemas de escribir código cliente en los browser son las incompatibilidades de sus APIs, que obligan a aplicar soluciones sumamente complejas para tareas triviales.
La solución a este tema son las librerías de más alto nivel que resuelven estos temas por nosotros, brindándonos de paso más funcionalidad lista para usar (y adecuadamente probada), minimizando la cantidad de código necesario por varios niveles de magnitud. El ejemplo más notorio de esta tendencia para mi es jQuery.
Problema 2 - Implementaciones
El rendimiento tradicional de Javascript no ha sido -digamos- brillante. Las implementaciones originales estuvieron pensadas para escenarios limitados y no en el uso intensivo que se le da actualmente. La manera en que se representan los objetos en memoria es poco eficiente, y por eso en aplicaciones complejas el desempeño empeora meteóricamente.
Varias soluciones están en camino. Tanto WebKit/Opera, como Mozilla/Firefox e Internet Explorer 8 siguen mejorando las implementaciones del lenguaje, pero más radicalmente, Microsoft está trabajando en su implementación de Managed JScript, que es una implementación basada en el Dynamic Language Runtime, que ejecuta JScript sobre el runtime de .NET (dentro del browser, utilizando Silverlight).
El inminente Chrome de Google utiliza también una máquina virtual llamada V8, que cambia radicalmente el ciclo de ejecución, compilando parte del código al código de la plataforma nativa, y mapeando las estructuras de datos a estructuras reales.
Problema 3 - Herramientas
Los entornos de desarrollo más usados para Javascript han sido tradicionalmente editores de texto, desde el espartano Notepad hasta los más profesionales VIM ó Notepad++.
Sin embargo, la explosión de Ajax ha provocado un nuevo acercamiento, y hoy hay IDEs mejores como Aptana, Spket, o el nuevo y mejorado Visual Studio 2008. También, el uso de Annotations en el lenguaje se ha popularizado como una manera de proveer mejor información a las IDEs sobre las API de las librerías y el código, mejorando las posibilidades de las herramientas de brindar feedback permanente.
Problema 4 - Lado servidor
Es cierto: este tema no parece tan importante todavía, pero existe, y tiene que ver con la brecha entre el modelo de programación del lado cliente y del lado servidor.
La primer medida para mejorar la situación es el creciente uso de JSON como formato de serialización, enviando datos desde el servidor al browser de manera que éste pueda realizar un Eval() y reproducir una estructura de datos sin necesidad de un parseo más costoso. Incluso Windows Communication Foundation ha incorporado JSON como un formato alternativo de intercambio de mensajes.
Sin embargo, estamos generando esto desde el servidor un tanto antinaturalmente, porque escribimos el código de ese lado en otra cosa (Python, PHP, C#, Ruby, etc). El siguiente paso, con las APIs adecuadas, y un motor de ejecución eficiente como el DLR ó V8, es utilizar Javascript del lado del servidor. En el mundo Java también hay varios proyectos trabajando fuerte en este sentido, como Phobos, Helma o Rhino.
Venciendo nuestros prejuicios
Ha llegado la hora. Con el soporte adecuado a nivel de ejecución, herramientas apropiadas y un buen conjunto de librerías, Javascript vuelve a ser un lenguaje que combina elegantes características dinámicas, funcionales y de prototipos. Tiene la sintáxis familiar de la familia C, y todos los desarrolladores web -en mayor o menor medida- hemos pasado por ahí.
¿En qué programaremos nuestras nuevas aplicaciones en dos o tres años más? Mi apuesta está hecha.
La versión final (release candidate) está disponible para que los desarrolladores puedan probar y ajustar sus aplicaciones antes de que el runtime llegue al público, en unas semans más (no hay fecha oficial todavía).
