martes, 1 de noviembre de 2011

Microframeworks en javascript

Cada vez más se están popularizando los llamados "microframeworks" de javascript. Estos microframeworks son pequeñas librerías que habitualmente pesan de menos de 5kb y que están centradas un temas muy concretos.

Uno de las frases que se utilizan para justificar el uso de estos microframeworks es que tan importante es lo que tienen como lo que no tienen. En librerías más tradicionales como jQuery hay mucha funcionalidad adicional que no se usa, código para compatibilidad con navegadores a los que tal vez no se vaya a dar soporte, etc. que hacen que las páginas pesen más, que tarden más en cargar, que tarden más en inicializarse, que se consumen más recursos del navegador, etc. Con los microframeworks solo utilizamos lo que sea imprescindible, pudiendo mejorar la experiencia del usuario.

Thomas Fuchs (autor de script.aculo.us, miembro del grupo que mantiene prototype.js y autor de la nueva y pequeña librería zepto.js) ha publicado recientemente un buscador de microframeworks llamado microjs en http://microjs.com.

Como no es oro todo lo que reluce, y sin ánimo de ser extensivo, voy a escribir algunos pros y contras de los microframeworks:

Pros
  • Los microframeworks suelen ser pequeños, compactos y poco acoplados, funcionando como módulos con los que componer aplicaciones
  • Los microframeworks se focalizan en resolver un problema y en resolverlo bien, eliminando duplicidades de código y piezas que no se usen.
  • Los microframeworks suelen tener un nivel de calidad de código bastante aceptable. Al tener que ser tan pequeños, exigen un esfuerzo a los desarrolladores que tendrán que aprender nuevas y mejores técnicas para poder resolver el objetivo concreto dentro de esos límites de tamaño establecidos.
  • Cada microframework, usado de manera individual resulta bastante sencillo de entender. En poquísimo tiempo se puede estar usando satisfactoriamente un microframework que se acabe de descubrir. Aunque la documentación no sea todo lo buena que quisiéramos, entrando en el código fuente podemos descubrir como funciona.
  • Muchos de estos microframeworks, al no estar acoplados a elementos de los navegadores, pueden usarse indistintamente en cliente y en servidor con node.js.

Contras

  • Las librerías tradicionales como jQuery, Dojo, Motools, etc. tienen una base de usuarios muy amplia y, gracias a ello, una madurez de la que carecen los microframeworks.
  • La compatibilidad con navegadores está garantizada dentro de lo posible. Cuando hay que dar soporte a usuarios con IE6, por ejemplo, esto es un gran activo.
  • La actualización de microframeworks puede convertirse en un problema si tenemos que estar manteniendo una aplicación que utilice muchos, mientras que con las librerías tradicionales, el upgrade de versiones resulta más directo.
  • La documentación está centralizada en un único sitio. Con los microframeworks habrá que revisar la documentación en un sitio por cada microframework, y esta documentación puede tener una calidad dispar. De cara a la mantenibilidad, esto puede impactar negativamente.
  • Si se empiezan a utilizar demasiados microframeworks a la vez, tal vez el peso conjunto supere al de una de estas librerías, perdiendo la ventaja inicial que proporcionaban.

Como siempre ocurre en tecnología, la decisiones sobre si utilizar una y otra aproximación dependerá de muchos factores, pero en mi caso, después de algunas experiencias con webapps para móviles con jquery mobile (24kb min+gzip  más los 31kb correspondientes de jquery), tengo muy claro que le voy a dar una oportunidad seria a los microframeworks.

Como muestra un botón

Hace poco descubrí un "micro" microframework con la funcionalidad de publish/subscribe que me resultó muy interesante.

Se usa de la siguiente manera:

    //suscribirse a un canal
    var handle = subscribe("/some/topic", function(msg){
        console.log(msg);
    });

    //publicar en el canal
    publish("/some/topic", ["first time"]);
    publish("/some/topic", ["second time"]);

    //eliminar la suscripcion
    unsubscribe(handle);

    //la suscripción ya no esta escuchando el canal
    publish("/some/topic", ["message will not be logged"]);


El código fuente, que minimizado y gzip pesa solo 198 bytes, es tan solo esto:

(function(d){var e=d.c_||{};d.publish=function(a,b){for(var c=e[a],f=c?c.length:0;f--;)c[f].apply(d,b||[])};d.subscribe=function(a,b){e[a]||(e[a]=[]);e[a].push(b);return[a,b]};d.unsubscribe=function(a){for(var b=e[a[0]],a=a[1],c=b?b.length:0;c--;)b[c]===a&&b.splice(c,1)}})(this);


El código fuente sin minimizar resulta bastante más inteligible. La librería se llama MinPubSub de Daniel Lamb y la podeis encontrar en https://github.com/daniellmb/MinPubSub .



No hay comentarios:

Publicar un comentario