La diferencia entre las bibliotecas y los frameworks de JavaScript

En este artículo, se explican las diferencias entre los frameworks y las bibliotecas en el contexto de un entorno de JavaScript del cliente, que es el código que se ejecuta en tu navegador web. Sin embargo, algunos de los puntos que se mencionan en este artículo también se aplican a otros entornos, ya que las bibliotecas y los frameworks forman parte de muchos campos de ingeniería de software, como el desarrollo de apps nativas para dispositivos móviles.

Los debates de esta publicación se centran en las diferencias cualitativas en lugar de las cuantitativas entre bibliotecas y frameworks. Por ejemplo:

  • Cuantitativo: Los frameworks suelen cumplir con el principio de inversión de control.
  • Cualitativa: La experiencia en el framework puede ser más atractiva para los futuros empleadores cuando busques trabajo.

¿Por qué aprender sobre bibliotecas y frameworks?

El uso de bibliotecas y frameworks de JavaScript es muy común en la Web. Todos los demás sitios web parecen usar algún código de terceros como parte de sus recursos de JavaScript. El peso de las páginas web empeora con el tiempo, lo que afecta a los usuarios. JavaScript es un factor importante que contribuye al peso general de la página, y es este mismo JavaScript el que suele incluir bibliotecas y frameworks de terceros.

No es suficiente decir "Deja de usar frameworks de JavaScript", ya que los frameworks proporcionan un gran beneficio a los desarrolladores. Los frameworks pueden ayudarte a codificar de manera eficiente y a entregar funciones con rapidez, entre otros beneficios. En cambio, debes informarte para poder tomar una decisión fundamentada cuando llegue el momento.

“¿Debo usar una biblioteca o un framework hoy?” es una pregunta poco común que te puedes hacer. Las bibliotecas y los frameworks son dos cosas muy diferentes. Sin embargo, las bibliotecas y los frameworks suelen confundirse, y cuanto más conocimiento tengas sobre ambos, es más probable que tomes decisiones fundamentadas sobre su uso.

Ejemplos de bibliotecas y frameworks

Es posible que notes el código de terceros con otros nombres, como widgets, complementos, polyfills o paquetes. Sin embargo, por lo general, todos pertenecen a la categoría de biblioteca o framework. Básicamente, la diferencia entre ambos se puede resumir de la siguiente manera:

Biblioteca

Las bibliotecas suelen ser más simples que los frameworks y ofrecen un alcance estrecho de funcionalidad. Si pasas una entrada a un método y recibes un resultado, es probable que hayas usado una biblioteca.

Observa este ejemplo de la biblioteca lodash:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

Como sucede con muchas bibliotecas, es práctico leer este código y comprender qué hace. No hay mucha magia:

  1. Una sentencia import importa la biblioteca lodash al programa de JavaScript.
  2. Se invoca el método capitalize().
  3. Se pasa un solo argumento al método.
  4. El valor que se muestra se captura en una variable.

Framework

Los frameworks suelen ser más grandes que las bibliotecas y contribuyen más al peso general de la página. De hecho, un framework puede incluir una biblioteca.

En este ejemplo, se muestra un framework simple sin biblioteca y se usa Vue, que es un framework de JavaScript popular:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

Si comparas este ejemplo de framework con el ejemplo de biblioteca anterior, es posible que notes las siguientes diferencias:

  • El código del framework abarca varias técnicas y las abstrae en su propia API definida.
  • Los desarrolladores no tienen control total sobre cómo y cuándo se realizan las operaciones. Por ejemplo, no tienes acceso a cómo y cuándo Vue escribe la cadena 'Hello, world' en la página.
  • La creación de instancias de la clase Vue tiene algunos efectos secundarios, que son comunes cuando usas frameworks, mientras que una biblioteca puede ofrecer funciones puras.
  • El framework prescribe un sistema de plantillas HTML en particular en lugar de usar el tuyo.
  • Si profundizas en la documentación del framework de Vue o en la mayoría de las demás, puedes ver cómo los frameworks prescriben patrones arquitectónicos que puedes usar. Los frameworks de JavaScript te quitan parte de la carga cognitiva porque no tienes que descubrirlo por tu cuenta.

Cuándo usar una biblioteca en lugar de un framework

Después de leer las comparaciones entre bibliotecas y frameworks, es posible que comiences a comprender cuándo usar uno o el otro:

  • Un framework puede reducir la complejidad para ti, el desarrollador. Como se mencionó, un framework puede abstraer la lógica, el comportamiento y hasta los patrones arquitectónicos. Es especialmente útil cuando comienzas un proyecto nuevo. Una biblioteca puede ayudar con la complejidad, pero por lo general se enfoca en la reutilización del código.
  • Los autores de los frameworks quieren que seas productivo y, a menudo, desarrollan herramientas adicionales, software de depuración y guías integrales, entre otros recursos, para ayudarte a usar un framework de manera eficaz. Los autores de las bibliotecas también quieren que seas productivo, pero las herramientas especializadas no son comunes en ellas.
  • La mayoría de los frameworks proporcionan un punto de partida funcional, como un esqueleto o un modelo, para ayudarte a compilar apps web con rapidez. Una biblioteca se convierte en parte de la base de código ya establecida.
  • En general, los frameworks agregan cierta complejidad a tu base de código. La complejidad no siempre es evidente al principio, pero puede revelarse con el tiempo.

Recuerda que, por lo general, no se compara una biblioteca con un framework porque son elementos diferentes que cumplen tareas distintas. Sin embargo, cuanto más conocimiento tengas sobre ambos, más poder tendrás para decidir cuál es la mejor opción para ti. La decisión de usar un framework o una biblioteca depende en última instancia de tus requisitos.

Intercambiabilidad

No cambiarás tu biblioteca o framework cada semana. Sin embargo, es recomendable comprender las desventajas de un paquete que te bloquea en su ecosistema. También te recomendamos que comprendas que el desarrollador que decide usar un paquete de terceros es en cierta medida responsable de la creación de una vinculación laxa entre el paquete y el código fuente de la app.

Un paquete vinculado al código fuente es más difícil de quitar y cambiar por otro. Es posible que debas cambiar un paquete en los siguientes casos:

  • Debes realizar actualizaciones en un paquete que ya no se mantiene.
  • Descubres que el paquete tiene demasiados errores para trabajar con él.
  • Conoces un nuevo paquete que satisface mejor tus necesidades.
  • Los requisitos de tu producto cambian y ya no se necesita el paquete.

Considera el siguiente ejemplo:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

En el ejemplo anterior, se usa el paquete @package/set-color de terceros en tres archivos independientes. Si trabajas en este código y necesitas reemplazar el paquete de terceros, debes actualizar el código en tres lugares.

Como alternativa, puedes simplificar el mantenimiento y abstraer el uso de la biblioteca en un solo lugar, como se muestra en este ejemplo:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

En el ejemplo anterior, se abstrae el uso directo de la biblioteca. Por lo tanto, si debes cambiar el paquete de terceros, solo debes actualizar un archivo. Además, ahora es más fácil trabajar con el código porque el archivo set-color.js interno establece un tema de color predeterminado para usar.

Facilidad de uso

Un framework puede tener una API compleja, pero podría ofrecer herramientas para desarrolladores que faciliten su uso en general. La facilidad de uso se basa en muchos factores y puede ser muy subjetiva. Un framework puede ser difícil de usar por los siguientes motivos:

  • El framework tiene una API inherentemente compleja.
  • El framework está mal documentado y requiere mucho ensayo y error para resolver problemas.
  • El framework usa técnicas que tú y tu equipo no conocen.

Los frameworks pueden mitigar estos desafíos mediante prácticas recomendadas comunes, como las siguientes:

  • El framework ofrece herramientas de diagnóstico y para desarrolladores para facilitar la depuración.
  • El framework tiene una comunidad activa de desarrolladores que colaboran en la documentación, las guías, los instructivos y los videos gratuitos. Después de consumir este contenido, podrás ser productivo con el framework.
  • El framework ofrece una API que sigue convenciones de codificación comunes. Eres productivo con el framework porque aprendiste esas convenciones anteriormente y tienes más familiaridad con los estilos de codificación.

Si bien estos puntos suelen atribuirse a los frameworks, también se pueden atribuir a las bibliotecas. Por ejemplo, la biblioteca de JavaScript D3.js es potente y tiene un gran ecosistema que ofrece talleres, guías y documentación, entre otros recursos, lo que influye en su facilidad de uso.

Además, un framework suele prescribir una arquitectura para tu app web, mientras que una biblioteca suele ser compatible con tu arquitectura existente, sea cual sea.

Rendimiento

En general, los frameworks pueden afectar el rendimiento más que las bibliotecas, aunque hay excepciones a este caso. El rendimiento web es un área enorme con muchos temas, por lo que estas secciones abordan dos temas importantes: el movimiento de árboles y las actualizaciones de software.

Eliminación de código no utilizado

El empaquetado es solo una faceta del rendimiento web, pero tiene un gran efecto en el rendimiento, especialmente con bibliotecas más grandes. El uso del desprendimiento de árboles durante la importación y exportación ayuda al rendimiento porque encuentra y poda el código que no es necesario para la app.

Cuando agrupas código JavaScript, hay un paso útil conocido como eliminación de árboles que es una optimización de rendimiento valiosa que puedes realizar en tu código, aunque es más fácil hacerlo con bibliotecas que con frameworks.

Cuando importas código de terceros a tu código fuente, por lo general, lo agrupas en uno o varios archivos de salida. Por ejemplo, los archivos header.js, footer.js y sidebar.js se combinan en el archivo output.js, que es el archivo de salida que cargas en tu app web.

Para comprender mejor el movimiento de árboles, considera estos ejemplos de código:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

A modo de demostración, el ejemplo de código de library.js se mantiene intencionalmente pequeño en comparación con lo que podrías encontrar en el mundo real, donde la biblioteca puede tener miles de líneas.

Un proceso de paquete ingenuo puede exportar el código con este resultado:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

Aunque no se necesita la función subtract() en esta app, se incluye en el paquete final. El código innecesario como este aumenta el tamaño de descarga, el tiempo de análisis y compilación, y los costos de ejecución que deben pagar tus usuarios. Un enfoque básico de eliminación de árbol quita el código no alcanzado y produce el siguiente resultado:

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

Observa que el código es más corto y conciso. En este ejemplo, la mejora del rendimiento es insignificante, pero en una app real en la que la biblioteca tiene miles de líneas, el efecto del rendimiento puede ser mucho más significativo. Curiosamente, las herramientas de paquetes modernas, como Parcel, Webpack y Rollup, van un paso más allá porque combinan la reducción y la eliminación de árboles para crear un paquete altamente optimizado. Para demostrar la eficacia de las herramientas de paquetes, usamos Parcel para crear un archivo de paquete con los ejemplos de código anteriores. Parcel quitó todo el código sin usar y exportó este único módulo:

console.log(7+10);

Parcel es lo suficientemente inteligente como para quitar instrucciones de importación, definiciones de funciones y comportamiento, entre otros elementos, para crear un código altamente optimizado.

El empaquetado es solo una faceta del rendimiento web, pero tiene un gran efecto en el rendimiento, especialmente con bibliotecas más grandes. Por lo general, el árbol de sacudidas es más fácil de hacer con bibliotecas que con frameworks.

Actualizaciones de software

En el caso de muchas bibliotecas y frameworks, las actualizaciones de software agregan funcionalidad, corrigen errores y, en última instancia, aumentan de tamaño con el tiempo. No siempre es necesario descargar actualizaciones, pero si estas incluyen correcciones de errores, mejoras de funciones deseadas o correcciones de seguridad, es probable que debas actualizar. Sin embargo, cuantos más datos envíes por cable, menor será el rendimiento de tu app y mayor será el efecto del rendimiento en la experiencia del usuario.

Si el tamaño de una biblioteca aumenta, puedes usar el agitado de árboles para mitigar el crecimiento. Como alternativa, puedes usar una alternativa más pequeña a la biblioteca de JavaScript. Para obtener más información, consulta Intercambiabilidad.

Si un framework crece de tamaño, no solo el movimiento de árboles es más desafiante, sino que puede ser más difícil cambiar un framework por otro. Para obtener más información, consulta Intercambiabilidad.

Empleabilidad

Es un secreto a voces que muchas empresas tienen requisitos estrictos para los desarrolladores que conocen un framework en particular. Es posible que ignoren tus conocimientos sobre los fundamentos de la Web y se enfoquen solo en tus conocimientos específicos sobre un framework de JavaScript determinado. Sea correcto o no, esta es la realidad de muchos trabajos.

El conocimiento de algunas bibliotecas de JavaScript no perjudicará tu postulación de trabajo, pero no hay garantías de que te haga destacar. Si conoces muy bien algunos frameworks de JavaScript populares, es probable que los empleadores consideren este conocimiento como favorable en el mercado laboral actual para desarrolladores web. Algunas organizaciones empresariales grandes están estancadas con frameworks de JavaScript muy antiguos y es posible que estén desesperadas por encontrar candidatos que se sientan cómodos con ellos.

Puedes usar este secreto abierto a tu favor. Sin embargo, debes abordar el mercado laboral con cautela y tener en cuenta las siguientes consideraciones:

  • Recuerda que, si dedicas una gran cantidad de tiempo de tu carrera a un solo framework, es posible que te pierdas experiencias de aprendizaje con otros frameworks más modernos.
  • Imagina a un desarrollador que no comprende de forma sólida los aspectos básicos del desarrollo de software o web, pero que se contrata como desarrollador de frameworks. Este desarrollador no escribe código eficaz y es posible que te resulte abrumador trabajar en una base de código de este tipo. En algunos casos, esta situación puede generar agotamiento. Por ejemplo, es posible que debas refactorizar el código o ajustar su rendimiento porque es lento.
  • Cuando aprendes desarrollo web, la mejor opción es comenzar con un enfoque intenso en los aspectos básicos del desarrollo web, el desarrollo de software y la ingeniería de software. Una base tan sólida te ayuda a elegir cualquier framework de JavaScript con rapidez y eficacia.

Conclusión

Felicitaciones por tu arduo trabajo para comprender cómo se comparan los frameworks y las bibliotecas de JavaScript. No elegirás frameworks ni bibliotecas con frecuencia, a menos que trabajes en proyectos de campo nuevo o como consultor. Sin embargo, cuando surgen esas decisiones, cuanto más conocimiento tengas sobre el tema, mejor fundamentada estará tu decisión.

Como aprendiste, la elección del framework que hagas (y, en algunos casos, la elección de la biblioteca) puede afectar de manera significativa tu experiencia de desarrollo y a los usuarios finales, como en el caso del rendimiento.