La diferencia entre las bibliotecas y los frameworks de JavaScript

Umar Hansa

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 mencionados en este artículo también se aplican a otros entornos porque 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 enfocan en las diferencias cualitativas en lugar de las diferencias cuantitativas entre las bibliotecas y los frameworks. Por ejemplo:

  • Cuantitativos: Los marcos de trabajo suelen cumplir con el principio de inversión de control.
  • Cualitativa: Cuando buscas trabajo, la experiencia en el marco de trabajo puede ser más atractiva para los futuros empleadores.

¿Por qué es importante aprender sobre bibliotecas y frameworks?

El uso de la biblioteca y el framework de JavaScript es prolífico en toda la Web. Todos los demás sitios web parecen usar código de terceros como parte de sus recursos JavaScript. El peso de la página web está empeorando con el tiempo, lo que afecta a los usuarios. JavaScript es un factor que contribuye en gran medida al peso general de la página y es el mismo JavaScript que, a menudo, incluye bibliotecas y frameworks de terceros.

No basta con decir "Dejar de usar frameworks de JavaScript", porque los frameworks brindan un gran beneficio a los desarrolladores. Los frameworks pueden ayudarte a programar de forma eficiente y entregar funciones con rapidez, entre otros beneficios. En cambio, debes educarte para poder tomar una decisión fundamentada cuando llegue el momento.

“¿Debería usar una biblioteca o un framework hoy?” es una pregunta poco común. Las bibliotecas y los frameworks son dos conceptos muy diferentes. Sin embargo, las bibliotecas y los frameworks a menudo se combinan y mientras más conocimiento tengas sobre ellos, más probable será que tomes decisiones fundamentadas sobre su uso.

Ejemplos de bibliotecas y frameworks

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

Biblioteca

Las bibliotecas suelen ser más simples que los frameworks y ofrecen un alcance limitado de funcionalidades. Si pasas una entrada a un método y recibes una salida, 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

Al igual que con muchas bibliotecas, es práctico leer este código y comprender lo que hace. Implica muy poca magia:

  1. Una sentencia import importa la biblioteca lodash al programa JavaScript.
  2. Se invoca al 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 una biblioteca y se usa Vue, que es un framework popular de JavaScript:

<!-- 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 del framework con el ejemplo anterior de la biblioteca, podrías notar estas diferencias:

  • El código del framework abarca múltiples técnicas y las abstrae en su propia API bien definida.
  • Los desarrolladores no tienen control total sobre cómo y cuándo se llevan a cabo las operaciones. Por ejemplo, se abstrae de ti la manera y el momento en que Vue escribe la cadena 'Hello, world' en la página.
  • La creación de instancias de la clase Vue lleva algunos efectos secundarios, que son comunes cuando se usan frameworks, mientras que una biblioteca puede ofrecer funciones puras.
  • El framework exige un sistema de plantilla HTML en particular en lugar de usar el tuyo.
  • Si lees más a fondo la documentación del framework de Vue o de la mayoría de las demás, podrás ver cómo los frameworks determinan los patrones arquitectónicos que puedes usar. Los frameworks de JavaScript te quitan la carga cognitiva porque no tienes que resolverlo por tu cuenta.

Cuándo usar una biblioteca frente a un framework

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

  • Un framework puede reducir la complejidad para ti, el desarrollador. Como se explicó, un framework puede abstraer la lógica, el comportamiento y hasta los patrones arquitectónicos. Es especialmente útil cuando comienzas un nuevo proyecto. Una biblioteca puede ayudar con la complejidad, pero, por lo general, se enfoca en la reutilización del código.
  • Los autores de frameworks quieren que seas productivo y a menudo desarrolles 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 bibliotecas también quieren que seas productivo, pero las herramientas especializadas no son comunes en las bibliotecas.
  • La mayoría de los frameworks proporcionan un punto de partida funcional, como un esqueleto o una plantilla, para ayudarte a compilar aplicaciones web rápidamente. Una biblioteca se vuelve parte de tu base de código ya establecida.
  • En general, los frameworks introducen cierta complejidad a tu base de código. La complejidad no siempre es evidente al principio, pero puede revelarse a lo largo del tiempo.

Recuerda que, por lo general, no debes comparar una biblioteca con un framework porque son elementos diferentes que realizan tareas distintas. Sin embargo, cuanto más conocimientos tengas sobre los dos, más facultado estarás para decidir cuál es la mejor para ti. En última instancia, la decisión de usar un framework o una biblioteca depende de tus requisitos.

Intercambiabilidad

No cambiarás tu biblioteca ni tu framework todas las semanas. Sin embargo, se recomienda comprender las desventajas de un paquete que te bloquea en su ecosistema. También es recomendable que comprendas que el desarrollador que decide usar un paquete de terceros es de alguna manera responsable de crear un acoplamiento bajo 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 intercambiar por otro paquete. Es posible que debas cambiar un paquete en los siguientes casos:

  • Debes actualizar un paquete que ya no se mantiene.
  • Descubres que el paquete tiene demasiados errores como para poder trabajar con él.
  • Aprenderás sobre un nuevo paquete que satisface mejor tus necesidades.
  • Los requisitos del producto cambian y el paquete ya no es necesario.

Observa este 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 separados. 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 puedes ver 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 actualizarás un archivo. Además, ahora es más fácil trabajar con el código porque el archivo interno set-color.js 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 los problemas.
  • El framework utiliza técnicas que tú y tu equipo no conocen.

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

  • El framework ofrece herramientas para desarrolladores y de diagnóstico que facilitan la depuración.
  • El framework cuenta con una comunidad activa de desarrolladores que colaboran en documentación, guías, instructivos y videos gratuitos. Una vez que consumes este contenido, eres productivo con el framework.
  • El framework ofrece una API que sigue las convenciones de programación comunes. Eres productivo con el framework porque aprendiste esas convenciones anteriormente y te familiarizaste más con los estilos de programación.

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

Además, un framework suele prescribir una arquitectura para tu aplicación web, mientras que una biblioteca suele ser compatible con tu arquitectura existente, sin importar cuál sea.

Rendimiento

En general, los frameworks pueden afectar el rendimiento más que las bibliotecas, aunque hay excepciones en este caso. El rendimiento web es un área muy extensa con muchos temas. Por ello, en estas secciones, se abordan dos temas importantes: la eliminación de código no utilizado y las actualizaciones de software.

Sacudida de árboles

Los paquetes son solo una faceta del rendimiento web, pero tienen un gran efecto en el rendimiento, especialmente con las bibliotecas más grandes. El uso de la eliminación de código no utilizado durante la importación y exportación ayuda al rendimiento, ya que encuentra y reduce el código innecesario para la app.

Cuando empaquetas el código JavaScript, existe un paso útil conocido como eliminación de código no utilizado que es una optimización de rendimiento valiosa que puedes aplicar a 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, debes empaquetar el código 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 la eliminación de código no utilizado, ten en cuenta 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));

Para fines de demostración, la muestra de código library.js se mantiene pequeña de manera intencional en comparación con lo que puedes encontrar en el mundo real, en el que la biblioteca puede tener miles de líneas.

Un proceso de paquete simple puede exportar el código con el siguiente resultado:

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

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

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

Si bien la función subtract() no es necesaria en esta app, se incluye de todos modos en el paquete final. Un 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 los usuarios. Un enfoque básico de eliminación de código no utilizado quita el código muerto 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 de longitud, el efecto en el rendimiento puede ser mucho más significativo. Resulta interesante que las herramientas modernas para los paquetes, como Parcel, Webpack y Rollup, van un paso más allá porque combinan la reducción y la eliminación de código no utilizado para crear un paquete altamente optimizado. Para demostrar la eficacia de las herramientas de paquete, 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 para quitar sentencias de importación, definiciones de funciones y comportamiento entre otros elementos para crear código altamente optimizado.

Los paquetes son solo una faceta del rendimiento web, pero tienen un gran efecto en el rendimiento, especialmente con las bibliotecas más grandes. La eliminación de código no utilizado suele ser más sencillo con las bibliotecas que con los frameworks.

Actualizaciones de software

Para 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 las actualizaciones incluyen correcciones de errores, mejoras de funciones deseadas o correcciones de seguridad, probablemente debas realizar la actualización. Sin embargo, cuantos más datos envíes por cable, menor será el rendimiento de tu app y mayor será el efecto en el rendimiento de la experiencia del usuario.

Si el tamaño de una biblioteca aumenta, puedes usar la eliminación de código no utilizado 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 en tamaño, la eliminación de código no solo representa un mayor desafío, sino que puede ser más difícil intercambiar un framework por otro. Para obtener más información, consulta Intercambiabilidad.

Empleabilidad

Es un secreto abrupto que muchas empresas tienen requisitos estrictos para los desarrolladores que conocen un framework en particular. Podrían ignorar tu conocimiento sobre los aspectos básicos de la Web y enfocarse solo en tus conocimientos específicos de un determinado framework de JavaScript. Bien o mal, esta es la realidad en muchos trabajos.

Conocer algunas bibliotecas de JavaScript no dañará tu solicitud de trabajo, pero no hay muchas garantías de que te destaques. Si conoces muy bien algunos frameworks populares de JavaScript, es muy probable que los empleadores consideren favorable para los desarrolladores web en el mercado laboral actual. Algunas grandes organizaciones empresariales están atascadas con frameworks de JavaScript muy antiguos e incluso pueden estar desesperadas por candidatos que se sientan cómodos con dichos frameworks.

Puedes sacar provecho de este secreto abierto. Sin embargo, aborda el mercado laboral con cautela y con estas consideraciones en mente:

  • Recuerda que, si le dedicas mucho tiempo a tu carrera con un solo marco de trabajo, es posible que te pierdas experiencias de aprendizaje con otros marcos de trabajo más modernos.
  • Considera a un desarrollador que no entiende muy bien los aspectos básicos del desarrollo de software o el desarrollo web, pero que aun así fue contratado como desarrollador de frameworks. Este desarrollador no escribe código eficaz, y puede que te resulte abrumador o abrumador trabajar en una base de código de este tipo. En algunos casos, esta situación puede conducir al agotamiento. Por ejemplo, es posible que tengas que refactorizar el código o ajustar el rendimiento porque es lento.
  • Cuando aprendes sobre desarrollo web, la mejor opción es comenzar con un enfoque profundo en los aspectos básicos del desarrollo web, el desarrollo de software y la ingeniería de software. Esta base tan sólida te ayuda a elegir cualquier framework de JavaScript de forma rápida y eficaz.

Conclusión

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

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