El lenguaje de programación más importante hoy en día
«¿Qué lenguaje de programación debería estudiar? ¿Cual framework?» de vez en cuando recibo correos electrónicos de lectores jóvenes – y no tan jóvenes – que me piden orientación sobre estos temas. «Usa la herramienta adecuada para el trabajo» es la respuesta correcta, pero es un consejo barato cuando hay una gran cantidad de herramientas al parecer adecuada para el trabajo. Para la mayoría de la gente en estos días el trabajo a realizar es el curso de desarrollo de aplicaciones web.
¿Deberían estudiar Ruby y Ruby on Rails? O ¿Python y Django? ¿Qué hay de C# 4.0 y ASP.NET MVC? ¿Tal vez CakePHP? ¿Java y Stripes? ¿Y que pasa con las alternativas más exóticas como Clojure y Compojure o Scala y Lift?
Con muy pocas excepciones, en el 2010, era difícil elegir una combinación de tecnologías semi-populares con las cuales no se podría hacer el trabajo. ¿Realmente hace una gran diferencia si eliges estudiar Ruby on Rails o Django? Con toda honestidad, a pesar de todas las diferencias existentes, en realidad no importa. Siempre y cuando te vuelvas hábil en una de estas herramientas, y estés adecuadamente preparado para abordar muchas de las tareas del desarrollo web. Tu experiencia como desarrollador del lado del servidor (server-side) será el cuello de botella, más no el framework que hayas elegido.
La verdadera razón por la que me hacen estas preguntas, es que estas personas en su mayoría están buscando la bala de plata, una combinación de framework-lenguaje que por arte de magia les permita crear fantásticas aplicaciones web en cuestión de semanas. Ellos están detrás de un atajo, pero no es el verdadero camino a la programación web.
Cuando pienso en el futuro de los lenguajes de programación, me imagino Babel sin gente hablando esperanto. Estamos destinados a vivir en un mundo tecnológico con muchas opciones validas del lado del servidor, que serán similares, pero lo suficientemente diferentes como para justificar su propia existencia y la de sus respectivas comunidades.
No va a existir un lenguaje de programación para gobernarlos a todos, pero creo que un lenguaje seguirá siendo la lengua franca de la web. En ese sentido, es el lenguaje de programación más importante de hoy y creo que su relevancia sólo seguirá creciendo en el futuro. Me refiero, por supuesto, a JavaScript.
Hoy JavaScript es el rey cuando se trata de programación web del lado del cliente. Nos llevó un tiempo llegar a este punto. En la mente colectiva, JavaScript se considera una lengua pobre utilizada por los aficionados para crear molestas páginas web. Hoy en día (gracias a AJAX, entre otros factores) es un lenguaje apreciado por muchos profesionales y utilizado por la inmensa mayoría de los desarrolladores web. Ya sea que las aplicaciones web se programen en Ruby, Python, Perl, PHP, C#, o algo más, vas a lidiar con JavaScript (que es el máximo común denominador de la comunidad de desarrollo web). No conozco a desarrolladores web muy pocos profesionales que no posean conocimiento superficial acerca de Javascript (o su primo, ActionScript).
En los últimos años, el navegador se ha convertido en la aplicación más importante en las computadoras de los usuarios. Esto a su vez, selló el destino de JavaScript para el futuro previsible. A pesar de sus muchos defectos, JavaScript es un lenguaje poderoso y elegante que cuenta con características avanzadas que están descaradamente ausentes en «auténticos» lenguajes como Java. Los programadores se han dado cuenta de su poder y su utilidad dentro del navegador. Hermosos frameworks de JavaScript como jQuery, YUI, y más recientemente SproutCore y Cappuccino (Objetive-J), mostraron el arte de lo que se puede lograr con este lenguaje. Y con HTML5 esta cada vez más cerca a la realidad, habrá un énfasis cada vez mayor en DOM scripting y una menor dependencia, siempre que sea posible, de plugins RIA.
Si en términos generales, JavaScript es un lenguaje sólido y potente que la mayoría de los desarrolladores web deben saber de todos modos, ¿por qué no podemos desarrollar así en JavaScript del lado del servidor? Y mientras estamos en ello, tal vez usarlo para aplicaciones de escritorio también. Parece lógico aprovechar los beneficios de tener un gran porcentaje de programadores utilizando el mismo lenguaje tanto para la programación del lado del cliente como del lado del servidor. (Si se requiere una actualización del lenguaje para limpiarlo un poco, vamos a hacerlo.) ¿Por qué no ser capaz de ejecutar js MyScript.js, fuera de un navegador, y obtener el resultado del cálculo? No hay ninguna razón intrínseca por la cual es necesario que JavaScript este vinculado al navegador.
Afortunadamente los tiempos están cambiando y respuestas concretas a las preguntas retóricas emergen. El motor V8 JavaScript es un proyecto que fue iniciado por Google, que nos proporciona una shell independiente para ejecutar scripts y probar el código en un REPL básico (leer-evaluar-imprimir-bucle). Es el mismo motor integrado en Google Chrome, y como tal, es una implementación rápida también.
Otro gran esfuerzo que se dirige en la misma dirección, y se basa en V8 es Node.js, un framework orientado a eventos E/S. Puedes pensar en el como Tornado, Twisted o EventMachine simplificados para JavaScript del lado del servidor. NodeJs no requiere tanto conocimiento acerca de los bucles de eventos y no-bloqueos de E/S, ni de los famosos callbacks que recuerda mucho el tipo de código AJAX que todos hemos visto antes. NodeJs puede ser utilizado como un servidor web básico ultra rápido, a la que se puede delegar los callbacks de E/S para mas escalabilidad y eficiencia.
Recientemente Heroku anunció soporte beta para NodeJs[1]. Es un riesgo, por su parte, pero vale la pena, en mi opinión. Sin nada más, y nada menos, los desarrolladores de Rails que desplegaron Heroku tendrán la opción de integrar NodeJs para aumentar la escalabilidad y el rendimiento.
Sin embargo, NodeJs (que incorpora el motor V8) tiene mucho más potencial que eso. El objetivo final es llegar a ser una solución independiente que permita desarrollar y desplegar código Javascript en el lado del servidor en modo de producción.
NodeJs es un destacado ejemplo del impacto del projecto/movimiento CommonJS, que tiene como objetivo hacer disponible a JavaScript fuera del navegador (en la servidores y escritorios). De hecho, hay un ecosistema de nuevas librerías .js que están destinadas a ser utilizadas con JavaScript del lado del servidor (es probable que crezcan con el tiempo).
Lo que realmente necesitamos es un framework web ligero que integre también Javascript en el lado del servidor y en el lado del cliente. Esto tendría el potencial de cambiar el juego (pensar en Rails de vuelta al 2004). Los desarrolladores se han acostumbrado a un alto nivel de abstracción cuando se trata de desarrollo web, sin embargo, por lo que hay un par de posibilidades: o bien NodeJs se convertirá en framework o alguien va a crear el framework (tal vez sobre NodeJs). Quien lo haga tendrá un pedazo del futuro y un billete de oro en sus manos.
[1] Para una demostración de Cappuccino + NodeJs existe en Heroku una excelente aplicación, echa un vistazo a GitHub.
Entradas relacionadas