Nunca salgo de mi asombro cada vez que leo que JavaScript ha repetido, un año más, en las estadísticas de GitHub como lenguaje más utilizado. Por favor, que alguien nos libre de esta cosa presuntamente creada en 10 días de 1995 por Brendan Eich y originalmente bautizada Mocha. Aunque no puedo sino reconocer el logro de Eich como grandioso, ese lenguaje multiparadigma útil para todo y bueno para nada, ese Lisp con sintaxis de C, nunca debió trascender los límites de Netscape. No voy a entrar en los tecnicismos que justifican por qué JavaScript es un campo minado, es fácil encontrar en Internet artículos como este o este que los comentan. En JavaScript la expresión ' \t\r\n ' == 0
devuelve true y similares a eso hy otra docena aquí.
La combinación de JavaScript con CSS3 es tan endemoniadamente traicionera que ningún programdor profesional los usa directamente sin librerías intermedias. Lo que voy a hacer, pues, es repasar las opciones que existen para tecnologías front-end en el navegador.
JavaScript presenta seis desafios principales cuando se usa como lenguaje de scripting en los navegadores web:
1. Cómo añadir contenido dinámicamente al árbol DOM del HTML.
2. Cómo gestionar cambios en CSS.
3. Cómo obtener información del servidor y sincronizarla con las variables locales de la página.
4. Cómo cargar dinámicamente sólo las librerías requeridas en cada página.
5. Cómo gestionar contenidos multimedia.
6. Cuestiones de estilo derivadas de la sintaxis de JavaScript.
Estos desafios son consecuencia de que cuando se creó JavaScript no se podía usar para añadir contenido dinámicamente a una página. Tampoco existía CSS. La idea era usarlo para hacer algunas validaciones de datos antes de un HTTP POST o crear transiciones de página que dependían de datos previamente seleccionados por el usuario.
El último punto tiene que ver en gran parte con que en JavaScript la programación orientada a objeto se puede hacer como una consecuencia de la estrutura interna del lenguaje donde las funciones son objetos que pueden tener propiedades definidas dinámicamente. Pero no existe una forma explícita de definir clases, implementación de interfaces y herencia como en los lenguajes orientados a objeto.
Hubo un tiempo en el cual la competición era crear extensos conjuntos de librerías que hicieran de todo. De aquella época han sobrevivido fundamentalmente JQuery y Dojo. A mi me gustaba YUI, sobre todo por su documentación superior al resto, pero, por desgracia Yahoo! decidió abandonarlo y lo reemplazó en parte por Pure. La tendencia más actual es hacia crear librerías más pequeñas de propósito específico.
Librerías JavaScript agrupadas según su funcionalidad principal
DOM, eventos y efectos | Carga dinámica de datos | CSS | Gestión de Configuración | Otras | Sintaxis |
JQuery Dojo Bootstrap |
AngularJS React.js Backbone.js |
LESS Sass Pure Zimit |
npm Bower RequireJS |
Modernizr Date.js plotly.js Textures.js Hammer.js Lightbox |
CoffeeScript PureScript ClojureScript Dart TypeScript ECMAScript6 |
Interfaz visual
JQuery
No se puede escribir sobre librerías JavaScript sin hacer referencia a JQuery. El núcleo de JQuery comprimido para producción ocupa 95Kb aunque cuenta con una arquitectura de plug-ins para extenderlo.
JQuery empieza por reemplazar el Javascript:
document.getElementById("hello");
por
$("#hello");
La notación $ permite usar selectores CSS. Por ejemplo, el siguiente fragmento añadirá un gestor de evento click a todos los tags de tipo <p> (párrafo).
$(document).ready(function(){
$("p").click(function(){
$(this).hide();
});
});
JQuery incluye selectores CSS, manejo de eventos, Ajax, y efectos visuales sobre capas. Es una librería de propósito general. Fácil de aprender y con una amplia comunidad de usuarios.
Dojo Toolkit
Dojo es una extensa librería de 13Mb. El gestor de dependencias básico pesa 117Kb. Tiene muchos módulos, incluidos widgets, MVC, grids, gráficos vectoriales, charting, validación de formularios, soporte HTML5, etc. Si lo que se busca es una librería que cubra el máximo de funcionalidades potencialmente requeridas, probablemente es la mejor opción. No obstante, a mi la curva de aprendizaje de dōjō siempre me ha echado para atrás. Basta con echar un vistazo al «Hello World!» de ejemplo.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Tutorial: Hello Dojo!</title>
</head>
<body>
<h1 id="greeting">Hello</h1>
<!-- load Dojo -->
<script src="//ajax.googleapis.com/ajax/libs/dojo/1.10.4/dojo/dojo.js"
data-dojo-config="async: true"></script>
<script>
require([
'dojo/dom',
'dojo/dom-construct'
], function (dom, domConstruct) {
var greetingNode = dom.byId('greeting');
domConstruct.place('<em> Dojo!</em>', greetingNode);
});
</script>
</body>
</html>
¡Mi madre! Trata de escribir semejante ejemplo intuitivamente. Usar dōjō es fácil cuando aprendes lo que tenían en la cabeza quienes lo diseñaron. Mientras tanto lo que es fácil es pasarse varias horas intentando averiguar cómo hacer algo tan trivial como añadir y quitar items en una combobox.
AngularJS
AngularJS es una librería de 150Kb creada principalmente para añadir contenido dinámicamente a una página. AngularJS tiene arquitectura MVVW. En palabras sencillas, funciona definiendo una plantilla a la que luego se pasan datos. Un buen ejemplo podría ser la creación de un scroll infinito similar al del archivo de un blog en Tumblr. La idea diferencial de AngujarJS sobre JQuery y Dojo es no manipular el árbol DOM directamente sino que al hacer cambios en el modelo de datos la librería los detecte dinámicamente y redibuje las plantillas afectadas. El «Hello World!» de los tutoriales es fácil de entender, pero para cargar datos dinámicamente mediante Ajax y presentarlos en pantalla la cosa tiene no poca complejidad adicional. Existen diferencias sustanciales entre la version 1.x y la 2.x de AngularJS, básicamente son dos productos diferentes y en la 2.x se usa TypeScript con un transcompilador. Por último, se pueden encontrar en Internet tantos tutoriales sobre cómo optimizar el rendimiento de AngularJS como para intuir incluso antes de hablerlo probado uno mismo que lo que hace por detrás la implementación no es precisamente ligero. Una librería MVC alternativa a AngularJS es Backbone.js que no voy a comentar aquí.
React.js
Originario de Facebook, el propósito de React.js es similar al de AngularJS pero a diferencia de este no es un framework MVC ni usa plantillas. La propuesta alternativa de React.js se llama JSX y es una mezcla de JavaScript con XML. Por ejemplo:
<script type="text/babel">
var CommentBox = React.createClass({
render: function() {
return (
<div className="commentBox">
Hello, world! I am a CommentBox.
</div>
);
}
});
ReactDOM.render(
<CommentBox />,
document.getElementById('content')
);
</script>
será traducido por React.js a
<script type="text/javascript">
var CommentBox = React.createClass({displayName: 'CommentBox',
render: function() {
return (
React.createElement('div', {className: "commentBox"},
"Hello, world! I am a CommentBox."
)
);
}
});
ReactDOM.render(
React.createElement(CommentBox, null),
document.getElementById('content')
);
</script>
Bootstrap
Bootstrap es una librería de componentes visuales salida de Twitter: botones, barras de navegación, dropdowns, etc. Está pensada para diseños responsive y soporte de dispositivos móviles. El núcleo pesa 37Kb y en total ocupa 1,1Mb en disco. La ventaja de Bootstrap es que proporciona un interfaz de usuario limpio y moderno «out-of-the-box» aunque también se puede personalizar.
Date.js
Haré una breve reseña sólo a mi librería favorita para solucionar el problema de las fechas en diferentes idiomas: Date.js.
LESS y Sass
LESS y Sass no son librerías JavaScript. Son preprocesadores de CSS. Nadie que pretenda escribir una hoja de estilos de más de 100 líneas debería planterse hacerlo sin usar alguno de estos preprocesadores. Yo siempre he usado LESS, pero últimamente parece ser que Sass se está imponiendo entre los creadores de opinión. El preprocesamiento puede hacerse en el lado cliente con Javascript o en el lado servidor mediante Rhino. Lo que permite básicamente es añadir variables a las hojas de estilo. Por ejemplo:
@backgroundcolor:white;
@textcolor:dimgray;
@textfont:Droid Sans,Arial,Helvetica,sans-serif;
html {
height:100%;background-color:@backgroundcolor;
}
body {
margin:auto;height:100%;font-family:@textfont;color:@textcolor;font-size:small;background-color:@backgroundcolor;
}
Sin el preprocesador habría que especificar el color de fondo white y el color de texto dimgray repetidos en html y en body.
Pure
La funcionalidad que me gusta de Pure es su herencia de los grids de YUI. Los grids son una forma de dividir la página verticalmente en fracciones del ancho. Por ejemplo
¼+¾ Los otros frameworks para diseño responsive como Zimit también pueden hacer esto, pero a mi Pure siempre me ha parecido el más práctico con el que comenzar.
Modernizr
Modernizr es un una librería que permite detectar si el navegador soporta o no una determinada funcionalidad. Se usa pues para variar el comportamiento en función de lo moderno (o no) que sea el navegador del usuario.
if (Modernizr.awesomeNewFeature)
showOffAwesomeNewFeature();
else
getTheOldLameExperience();
Otras librerías
Existen decenas de pequeñas librerías para tareas específicas: crear mapas con zonas clickables, pop-ups, etc. Ya en 2013 Juantomás publicó un enlace a una extensa lista de frameworks CSS3.
Gestión de la configuración
npm
El gestor de paquetes que se está estandarizando para Javascript es npm. npm viene incluído con Node.js (de hecho para instalarse npm hay que instalarse Node.js). npm permite definir modulos y almacenarlos en un repositorio desde el cual se pueden cargar dinámicamente mediante un comando require().
Bower
Por encima de npm es posible utilizar Bower. Bower se instala com npm y proporciona funcionaldiades específicas para la gestión de la configuración en aplicaciones web.
Require.js
Por último, una vez que se tienen instalados los paquetes en el servidor se pueden cargar dinámicamente en el navegador con RequireJS. RequireJS se puede usar con JQuery, Dojo y Bower.
Alternativas sintácticas
Existe una gran cantidad de lenguajes que pueden traducirse a JavaScript. Personalmente yo no he llegado a utilizar ninguno de ellos en producción pues todos me han parecido propuestas para cambiar el estilo sintáctico tipo C de Javascript por el de Python y Ruby (CoffeeScript), el de Haskell (PureScript), el de Lisp (ClojureScript), o el de C++ (Dart). Quizá una alternativa interesante sea TypeScript en tanto en cuanto no pretende como el resto cambiar la sintaxis del lenguaje sino permitir la anotación de tipos y la definición de interfaces y clases como extensiones al propio JavaScript. Por último, vale la pena echar un vistazo a las novedades en ECMAScript 6 que incluyen clases, cargadores de módulos y otras funcionalidades hasta ahora sólo disponibles a través de librerías y precompiladores.
Conclusiones
Desde la aparición de la WWW, ha habido un incremento constante de las funcionalidades presentes en el lado cliente. Este incremento en la demanda, no ha podido ser atendido con suficiente rapidez por los estándares. Por consiguiente, han proliferado muchas librerías y tampoco se ha llegado a un acuerdo sobre la mejor manera de utilizarlas.
Antes de empezar a escribir la aplicación hay que hacer una lista de requerimientos y mapearlos con las librerías que serán necesarias. ¿Es una aplicación web para gestión desde un desktop o debe tener soporte smartphone? ¿Presenta sólo páginas estáticas con algún efecto visual o carga contenidos dinámicamente mediante Ajax? ¿Requiere gráficos SVG o charting? ¿Necesita soporte multi-idioma? etc.
Para el principiante que no quiera complicarse lo mejor es probablemente empezar por JQuery, LESS y Pure. Bootstrap es una buena opción para aplicaciones de gestión que requieran muchos controles de entrada (botones, menús, pestañas, etc.)
AngularJS y React.js requieren algo de esfuerzo para aprender a utilizarlos el vale la pena sólo si las páginas deben cargar dinámicamente datos del servidor en respuesta a eventos generados por el usuario.
Por último, si usaste estas u otras librerías, deja un comentario sobre tu experiencia :)
Pingback: Cómo seleccionar una plataforma de desarrollo para un proyecto web | La Pastilla Roja