Archivo de la etiqueta: Node.js

El caso NPM y la forma en la que gestionamos las dependencias en proyectos de software

npm-logoJavascript se encuentra en su edad de oro en estos momentos. A pesar de llevar décadas con nosotros es ahora cuando este lenguaje de programación ha conseguido un éxito que nunca antes ha tenido y últimamente he oído en varios sitios que es el lenguaje de programación más utilizado del mundo (no sé si será cierto).

Sin duda la llegada de HTML5 por un lado y la aparición de una tecnología como Node.js por otro han hecho que el espacio en el que se mueve Javascript haya crecido exponencialmente y además se haya mostrado como una opción totalmente válida en esos territorios que ha ‘colonizado’. En los últimos años han aparecido miles de frameworks, librerías y herramientas y la mayoría de ellos son de código abierto. Con la llegada de tal número de opciones se vio la necesidad de una ayuda a la hora de poder hacer uso de ellas y es aquí cuando llegaron herramientas como npm (Node Package Manager) o Bower, con las cuales podemos gestionar todas las herramientas que utilizaremos en nuestros proyectos de forma que se eliminan gran parte de los quebraderos de cabeza que surgían antes.

Que herramientas como Bower y npm son un paso adelante está más que claro, pero esto no quiere decir que su uso no vaya a generar problemas. Hace poco miles de programadores aprendieron de forma bastante poco cómoda que estos problemas son reales y que utilizar componentes de terceros puede ponernos en una situación delicada si no tenemos un poco de cuidado. El tema es que las herramientas de terceros que utilizamos en nuestros proyectos no dejan de ser dependencias, es decir, nuestro proyecto dependerá de ellas porque las necesitará para funcionar.

Siendo ésta la situación podría pasar que en caso de que una de las dependencias cambie algo en su código nosotros tengamos que hacer cambios también para adaptarnos a dichos cambios. Este hecho suele ser bastante habitual en el mundo del desarrollo de software y las librerías y frameworks que están bien mantenidas suelen avisar con bastante antelación de cambios que no sean compatibles hacia atrás.

Pero en la situación que he mencionado más arriba no hubo ningún aviso previo. La historia es la siguiente: el dueño de un módulo npm llamado Kik tuvo una disputa con la empresa que tiene el mismo nombre debido al nombre de marras y cuando la propia npm se posicionó del lado de la empresa el desarrollador decidió eliminar todos sus proyectos de dicha web. Como es habitual entre los usuarios de npm este usuario tenía multitud de proyectos y resulta que uno de ellos era uno llamado Left-pad. Podríamos decir que este proyecto es bastante simplón ya que se compone de un único fichero de 17 líneas.

Sin embargo este pequeño proyecto no era de esos que sólo conoce y usa su creador. Proyectos gigantes como Babel o Atom utilizaban Left-pad en su código, es decir, dependían de Left-pad. La desaparición del pequeño componente a causa de la disputa por el nombre causó que proyectos de tal envergadura dejaran de funcionar y con ello despertó el debate en torno a npm y las dependencias.

En mi caso lo que suelo intentar al iniciar un proyecto es aplicarme la ley de generar el mejor número de dependencias posible. A veces las cosas no van como uno quiere y acabamos teniendo una interminable lista de dependencias en el fichero de configuración de npm y también es cierto que volver a hacer algo que ya está hecho es perder el tiempo, así que no estoy diciendo que utilizar el trabajo ofrecido por otros sea mala idea. Lo que pretendo decir es que añadir dependencias constantemente puede traer problemas en el futuro.

Por tanto, sabiendo esto, mi filosofía es intentar usar el menor número de dependencias posible. Si necesito un pedazo de código muy pequeño, digamos una función o dos, suelo preferir implementarlo yo a importarlo de otro lugar y debido a esto creo que un caso como el de Left-pad no hubiera afectado a uno de mis proyectos. Pero que nadie piense que esto es porque soy más listo que el resto del mundo, simplemente es así por la forma de trabajar que yo he escogido. Seguramente Left-pad es una herramienta totalmente fiable y testada y puede ser que yo hubiera introducido algún error en mi propia implementación que en este caso no hubiera afectado a Atom o Babel.

Una cosa es clara: cuantas más dependencias tengamos más complejo (tanto por ser más grande como por tener partes no hechas por nosotros), potencialmente con menor rendimiento (sobre todo en aplicaciones para navegadores, cuanto más código tengamos más tiempo hasta falta para descargar todo y poner la solución a correr) y más difícil de gestionar (porque tendremos que tener bajo control la evolución de las dependencias para evitar que cambios en las mismas hagan que nuestro trabajo deje de funcionar) será el proyecto. Mi recomendación es que antes de añadir una dependencia nos hagamos las siguientes dos preguntas:

  • ¿De verdad necesito esta dependencia?
  • ¿Es ésta la dependencia que realmente cubre mis necesidades?

Creo que le segunda pregunta es muy interesante. Normalmente las librerías y frameworks hacen muchas cosas y puede ser que nuestro proyecto no vaya a usar la mayoría de ellas. Por ejemplo, no tiene ningún sentido utilizar Angular.js en un proyecto si lo único que nos interesa es el enlazado de datos (two way data-binding). Estoy seguro de que hay otras opciones que ofrecen solamente esta funcionalidad y en este caso concreto Angular.js es claramente una dependencia excesiva.

En resumen, mi opinión es que es mejor tener el menor número de dependencias posible y que éstas estén bien escogidas para que hagan únicamente lo que necesitamos, ni más ni menos. Y por supuesto, aún con sus problemas, recomiendo encarecidamente usar herramientas del estilo de npm o Bower porque facilitan mucho la gestión de las dependencias.

Node.js Foundation llega para poner fin a la crisis interna del proyecto

nodejs-1280x1024Node.js es una de las tecnologías del momento. Es uno de los actores que valiéndose del éxito que está viviendo el lenguaje de programación Javascript en el que se basa está consiguiendo que éste último supere las fronteras que tradicionalmente le mantenían dentro de los navegadores web.

Normalmente se define a Node.js como la plataforma que permite el uso de Javascript en el lado servidor pero en realidad éste puede hacer más cosas como por ejemplo automatizar tareas del ordenador o permitir el desarrollo de aplicaciones de escritorio.

Sin embargo, todo sea dicho, es verdad que la principal razón de su éxito de fundamenta en haberse convertido en una opción como tecnología de servidor. El acrónimo tan conocido en el mundo de programación llamado LAMP (Linux, Apache, MySQL, PHP) ha encontrado un duro competidor: MEAN (MongoDB, Express, Angular, Node.js). El concepto MEAN utiliza Javascript de principio a fin y Node.js es una pieza clave en su funcionamiento. De hecho hay grandes empresas que empiezan a adoptar este paradigma sustituyendo a herramientas basadas en Java que llevan ya años entre nosotros.

Se puede ver, por tanto, que ésta es una tecnología con un futuro muy prometedor. Sin embargo, durante los últimos meses hemos vividos algunos sucesos que han puesto la paz dentro del proyecto en entredicho. La razón principal es que hay algunas personas que no están de acuerdo con la gestión de la empresa llamada Joyent, sponsor del proyecto. Como agravante, las personas en desacuerdo son algunas de las que más aportaciones daban al proyecto y su decisión ha sido drástica: el pasado diciembre decidieron crear un fork de Node que fue bautizado como IO.js. Al parecer el núcleo del desacuerdo viene de la política conservadora y lenta de Joyent en cuanto al plan de lanzamientos y la falta de una organización interna basada en el llamado open government.

En diciembre, por lo tanto, surgieron las primeras dudas en torno al proyecto viendo que podía surgir una desestabilización en una tecnología tan en auge. Pero a pesar de todo, y visto desde la distancia, parece que las dos partes están teniendo un comportamiento bastante correcto, sin generar luchas innecesarias. IO.js declaró desde el primer momento su intención de aportar sus avances al proyecto Node y Joyent recientemente hizo públicos los primeros pasos para cambiar la organización interna a un modelo de open government. Visto ésto el final de las hostilidades parece estar más cercano si bien IO.js esperará hasta ver qué forma coge la nueva organización de Node.js.

Esta historia nos muestra cómo una tecnología muy prometedora se ve en peligro por razones que traspasan el ámbito puramente tecnológico, si bien también enseña que si existe un verdadero deseo de superar los problemas las situaciones siempre pueden reconducirse. De momento hay razones para el optimismo pero habrá que ver cómo se dan los siguientes pasos de cara a zanjar definitivamente el problema.