Este post no es para tratar de convenceros de que os unais a las legiones de Javascript, sino para explicar mis razones para tomar ese camino de perdición. Antes que en javascript programé en tres o cuatro lenguajes, principalmente C y Java. Por supuesto en la universidad aprendí LISP, PROLOG, ADA, varios dialectos de ensamblador y alguna cosa más, pero como nos lo he vuelto a tocar desde entonces no los considero parte de mi «toolkit».
Yo empecé en esto de Javascript como la mayoría de vosotros, haciendo unos scripts güarrotes para validaciones y efectillos, en los tiempos del año 2000. Era un mal necesario con el que tenía que convivir al desarrollar mis preciosas aplicaciones thin-client en Java. Sin embargo sobre 2005, empecé a querer usar servicios REST sin sesión por temas de rendimiento, lo que me hizo repensar la arquitectura de mis sistemas. Fue entonces cuando descubrí AJAX, y me quede fascinado por las posibilidades. Desde entonces fue un camino sin retorno; cada vez que aprendía más, descubría nuevas tecnologías, y reflexionaba más sobre como diseñar mejor mis aplicaciones, más enganchado me quedaba con Javascript, y desde entonces hasta ahora.
Así que, ¿por qué Javascript?
Es ubíquo
Que yo sepa, es el lenguaje que en la actualidad está más extendido del mundo. Virtualmente en cada ordenador de cada casa se puede ejecutar una versión u otra de Javascript. ¿Qué ordenador no tiene un browser? ¿Al menos un IE6? Sí, algunas personas por motivos de accesibilidad o seguridad no lo tienen disponible, pero son una exigua minoría.
¿Y en servidor? Pues ya sabeis que tenéis el node.js, tenéis Rhino, etc. En concreto en node.js se está invirtiendo cantidades ingentes de dinero. Ya está soportado en algunas plataformas cloud, como Heroku/Cedar y Windows Azure.
¿Y en desktop? Pues desde hace tiempo existe la plataforma Mozilla, ¿en que creéis que se programa la mayor parte de Firefox y Thunderbird? En una mezcla de Javascript (y C para el bajo nivel). Además Windows 8 plantea usar a JavaScript como uno de los lenguajes de preferencia para hacer aplicaciones de escritorio (otorgándole el mismo rango que a C#).
El mismo lenguaje para cliente y servidor
A día de hoy Javascript es el único lenguaje en el que puedes desarrollar por completo una aplicación web de punta a punta, desde la UI hasta el acceso a BBDD. ¿Qué tiene esto de interesante?
- No necesitas dominar más de un lenguaje para hacer la aplicación web. Esto te permite no estar cambiando de contexto entre un lenguaje y otro, o simplemente no necesitar dos equipos de desarrollo especializado (uno de front-end y otro de server-side). Además de aumentar tu productividad, puede facilitar tener un equipo de proyecto más cohesionado.
- No necesitas recodificar la misma lógica tanto en Javascript como en el lenguaje que estés usando en tu server-side. ¿Modelos de negocio? ¿Validaciones? Todo eso es único y debería ser reutilizable tanto en tu front-end como en tu server-side. Si lo haces todo en Javascript, terminas teniendo un montón de código común en ambos lados, que antes tendrías que haber duplicado y mantenido en dos lenguajes diferentes. Eso sí, hay que diseñar tu arquitectura de la forma adecuada para que esto se pueda cumplir.
- Estándares de codificación y criterios de calidad unificados para todas las capas de tu sistema.
Tipado dinámico
Confieso que este punto es muy subjetivo. Ya sabeis que soy un fanático del TDD. Y si haces TDD como es debido, al final el compilador deja de ser tan valioso. Los errores de sintaxis o de tipos son muy sencillos de detectar y arreglar usando TDD, no necesitas un compilador para ello. En los lenguajes de tipado estático, el compilador detecta este tipo de errores, pero a cambio tienes que esperar a que éste se termine de ejecutar. Además normalmente tendrás que escribir más código, para añadir toda la información de tipado que el compilador necesita. Esto hace que el ciclo de TDD sea algo más lento que en un lenguaje de tipado dinámico. Ya que TDD me va a detectar esos errores de todas formas, no me resulta rentable el «trade-off» propuesto por el compilador.
Dicho esto, si no hacéis TDD, mucho cuidado con Javascript, puede ser un buen dolor de muelas de depurar, e incluso pequeños fallos de sintaxis te pueden llevar por el camino de la amargura. Para mi lo ideal del TDD es no tener que depurar, o si lo tengo que hacer, que sea sobre 4 o 5 líneas de código bien identificadas, y que están siendo ejercitadas por un test predecible. Desde este punto de vista Javascript no plantea ningún problema.
Paradigma mixto
Es un lenguaje que te permite hacer OO hasta de dos formas diferentes, con «extends» y sin «extends». Pero es que además también puedes hacer programación funcional con él. Esto te permite elegir el paradigma de programación que mejor se adapte al problema a resolver.
¿Tratamiento de colecciones? ¿Cálculos puros (validaciones, reglas de negocio)? ¿Programación asíncrona? Mejor el paradigma funcional
¿Modelado de negocio? ¿DDD? Mejor OO
Y por supuesto en una aplicación de verdad vas a tener que usar ambos paradigmas, y mezclarlos armoniosamente. Incluso a veces los puedes mezclar de tal forma que llegan a ser difícil de distinguir uno de otro.
Flexible
Es un lenguaje ideal para hacer DSLs internos, gracias a su gran flexibilidad. Puedes añadir y eliminar funciones al vuelo tanto en una instancia como un constructor. Esto no sólo te permite crear DSLs sino añadir nuevas capacidades al lenguaje, y realizar metaprogramación (aunque en Ruby y Groovy se puede llegar incluso más lejos).
Reconozco que esto puede ser una fuente de problemas, y es mejor evitar este tipo de funcionalidades. Por ello las últimas versiones de Javascript te permiten cerrar total o parcialmente un objeto, para evitar que se puede modificar en tiempo de ejecución. Sin embargo en algunos casos está justificado hacer este tipo de cosas. Aparte de los DSLs y quizás algunos ejemplos de metaprogración, el caso más importante es el de retrocompatibilidad. ¿Qué ocurre si estoy ejecutándome en una máquina virtual de Javascript que no soporta la API de colecciones de la última versión de Javascript? ¿Y si estoy en un navegador que no soporta alguna API de HTML5? ¡No hay problema! Con Javascript puedo detectar tal eventualidad y añadir la API que me falta de forma dinámica. Este tipo de capacidad ha permitido a Javascript sobrevivir en el infierno de incompatibilidades de los distintos browser por más de 10 años.
¿Y los WTF?
Sí, Javascript tiene algunos WTF. Sólo es cuestión de comprenderlos y saber que están ahí. Por ejemplo, los ámbitos de visibilidad no se señalan con ‘{‘ y ‘}’. En Javascript las llaves son prácticamente cosméticas y sólo sirven para agrupar el cuerpo de bucles y condicionales. Otra tema es el hoisting de variables, o el hecho de que en Javascript no existan los números enteros sino que sean todos en coma flotante. Personalmente el WTF que más me molesta es que Javascript tiende a ser «listillo». Esto significa que intenta no fallar nunca con excepción. De ahí el horroroso e infernal sistema de coerción de tipos o el abuso de null y NaN en mucha de las librerías del lenguaje. En esto sí es verdad que se sufre.
Sin embargo los WTF de Javascript no son tantos ni tan difíciles de aprender como la gente piensa. La mala fama de Javascript viene por causas totalmente ajenas al lenguaje, los WTF de los navegadores. Tradicionalmente la implementación de los navegadores de los estándares de manipulación de HTML y de los servicios estandarizados por W3C ha sido defectuosa. Eso ha causado multitud de quebraderos de cabeza a los desarrolladores. Realmente, en la mayor parte de los casos, cuando un desarrollador piensa en las heridas recibidas en acto de servicio por parte de Javascript, normalmente debería achacarle la culpa al navegador. Desgraciadamente hasta hace poco navegador y lenguaje han estado mezclados en las mentes de los desarrolladores.
El pero
No todo es bonito en el lenguaje. Hay varios problemas con Javascript. El primero, y más importante, son los WTF arriba mencionados. El segundo es la sintaxis tan fea que tiene. La verdad de que con esto de querer simular ser C o Java la pifiaron bien. Espero que en siguientes versiones del lenguaje arreglen todo esto. Si no de momento podemos usar «strict mode»; para desactivar la mayor parte de los WTF, o usar CoffeeScript. El caso de CoffeeScript es curioso, si sabes Javascript entonces CoffeeScript te parece un simple dialecto de Javascript. Si no conoces Javascript, te parecerá un lenguaje totalmente diferente. El caso es que CoffeeScript soluciona la mayor parte de los WTF de Javascript, y tiene una sintaxis mucho más elegante. Lo tengo en el punto de mira a ver como se desarrolla.
Estos son los problemas que reconozco con el lenguaje. Después hay problemas humanos. Ese programador de Java que intenta programar en Javascript como si fuera un hermano retardado de Java (me incluyo en los culpables). Claro, intentas que una manzana se parezca a un plátano, y después vas echando pestes de lo feas que son las manzanas. No critiquemos el lenguaje sólo porque tengamos un conocimiento superficial de este, y al intentar programar como lo hacemos en nuestro lenguaje server-side, las cosas no nos salgan bien. ¡Es como si yo ahora digo que Clojure es una mierda porque no me termino de acostumbrar a su sintaxis y no puedo hacer una asignación de variable de forma sencilla! (no sería mal post 😀 )
También hay que reconocer que no es un lenguaje sencillo de aprender. Primero tienes que aprender los WTF, para desarrollar instintivamente buenas prácticas que los eviten. Después tienes que ser capaz de dominar dos paradigmas de programación distintos, OO y funcional. Sólo así conseguirás sacarle toda la potencia a Javascript.
Conclusión
Desde mi punto de vista a día de hoy Javascript es el lenguaje más adecuado para desarrollar aplicaciones web. El problema es que no tiene competencia, ¿qué otro lenguaje tiene unas características similares a las anteriormente mencionadas? Yo no conozco ninguno. Ciertamente Ruby es bastante elegante, y me gusta bastante, ¡ pero sólo se ejecuta en servidor ! Java no está envejeciendo nada bien, y aunque C# es más avanzado está mucho menos extendido y tampoco se ejecute en servidor. Lo mismo puede decirse de Clojure, Scala o Groovy. Sí, podemos hacer como GWT o ClojureScript y compilar estos lenguajes en Javascript, pero, ¿con qué fin? La experiencia GWT ha resultado fallida.
En cualquier caso, a día de hoy, programes en el lenguaje que programes, si quieres hacer aplicaciones web modernas, te toparás con Javascript. Así que es mejor aprenderlo y dominarlo.
Tal vez en el futuro salga un nuevo lenguaje, con más ventajas que Javascript para hacer aplicaciones web. En ese momento tiraré Javascript a la basura y me pondré con el nuevo lenguaje, pero me temo que aun quedan 10 años para eso.
¡Espero que os hayan sentado bien las torrijas de Semana Santa!
Te lo dije ... 