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: Por lo general, los frameworks se adhieren al 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 basta con decir “deja de usar los frameworks de JavaScript”, porque estos brindan un gran beneficio a los desarrolladores. Los frameworks pueden ayudarte a programar de forma eficiente y entregar funciones rápidamente, entre otros beneficios. En cambio, debes informarte para poder tomar una decisión fundamentada cuando llegue el momento.
No es común preguntarse si deberías usar una biblioteca o un framework. 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, más probabilidades tendrás de tomar 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, todas suelen entrar en la categoría de una biblioteca o un framework. Básicamente, la diferencia entre ambos se puede resumir de la siguiente manera:
- En el caso de una biblioteca, el código de tu app llama al código de la biblioteca.
- En el caso de un framework, el framework llama al código de tu app.
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 ocurre con muchas bibliotecas, es práctico leer este código y comprender qué hace. Puedes usar muy poca magia:
- Una sentencia
import
importa la biblioteca lodash al programa JavaScript. - Se invoca el método
capitalize()
. - Se pasa un solo argumento al método.
- 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 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 estas 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 marco de trabajo prescribe un sistema de plantillas HTML específico en lugar de usar el tuyo.
- Si lees más en la documentación del framework de Vue o en la mayoría de las demás documentación de los frameworks, podrás ver cómo los frameworks establecen los patrones arquitectónicos que puedes usar. Los frameworks de JavaScript te quitan un poco de la carga cognitiva porque no tienes que averiguarlo tú mismo.
Cuándo usar una biblioteca en lugar de un framework
Después de leer las comparaciones entre bibliotecas y frameworks, es posible que empieces a entender cuándo usar uno de los dos:
- 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 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 frameworks quieren que seas productivo y que, a menudo, desarrollen 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 introducen 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 realizan 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 las siguientes situaciones:
- Debes actualizar un paquete que ya no recibe mantenimiento.
- Descubres que el paquete tiene demasiados errores para trabajar con él.
- Conoces un nuevo paquete que satisface mejor tus necesidades.
- Los requisitos del 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 de mucho ensayo y error para resolver los 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 desarrollador y de diagnóstico para facilitar la depuración.
- El framework tiene una comunidad activa de desarrolladores que colaboran en documentación, guías, instructivos y videos gratuitos. Después de consumir este contenido, podrás ser productivo con el framework.
- El framework ofrece una API que sigue convenciones de programació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 en este caso. El rendimiento web es un área enorme con muchos temas, por lo que en estas secciones se tratan dos temas importantes: la eliminación de código no utilizado y las actualizaciones de software.
Eliminación de código no utilizado
Los paquetes son solo una faceta del rendimiento web, pero tiene un gran efecto sobre el rendimiento, especialmente con las bibliotecas más grandes. El uso de la reducción de árbol 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 hacer en tu código, aunque es más fácil hacerlo con bibliotecas que con frameworks.
Cuando importas código de terceros al 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 la eliminación de árboles, 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));
A los fines de la demostración, la muestra de código library.js
se mantiene intencionalmente pequeña en comparación con lo que podrías encontrar en el mundo real, donde la biblioteca puede tener miles de líneas de longitud.
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 código no utilizado quita el código muerto y produce este 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 para quitar sentencias de importación, definiciones de funciones y comportamientos 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 las actualizaciones incluyen correcciones de errores, mejoras de funciones deseadas o correcciones de seguridad, probablemente debas actualizarla. Sin embargo, cuantos más datos envíes, menor será el rendimiento de tu app y mayor será el efecto en el rendimiento de la experiencia del usuario.
Si una biblioteca aumenta de tamaño, 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 aumenta 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
No es cierto que muchas empresas tienen requisitos estrictos para los desarrolladores que conocen un framework en particular. Es posible que ignoren tus conocimientos sobre los aspectos básicos de la Web y se enfoquen únicamente en tu conocimiento específico de un marco de trabajo 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 pasas una gran cantidad de tiempo en tu carrera con un solo marco, puedes perderte experiencias de aprendizaje con otros frameworks más modernos.
- Imagina 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 surjan 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 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.