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.
2 comentarios:
Hola. Interesante artículo, el futuro V8. Como curiosidad, ¿qué opinión te merece X3d (o extensible 3D)? Sabia programar en HTML allá por el año 92 y con tanto editor visual me desilusioné. Ahora que si XHTML 1.0 que si HTML 5.0... no sé muy bien adonde caminar mis pasos porque el vRML me parecio muy interesante pero no adquirio auge. En fin, ¿cómo ves el futuro en estos lenguajes?
P.D. He añadido tu espacio web a mis favoritos, está muy interesante. Muchas gracias
Con lo que comentas respecto a programar con JavaScript del lado del servidor, Aptanta tiene una solución llamada Jaxer, que hace justamente eso. Algo medio "loco" como las páginas ASPX donde definis scripts (JavaScripts) que corran del lado del servidor. Del lado del servidor tendrías un copia del DOM y también lo podrías manipular.
Bueno, cosas que surgen, el tiempo dirá si tienen o no éxito.
Saludos!
Publicar un comentario