TL; DR: La mayor diferencia en el uso diario no son las dependencias anidadas ... es la diferencia entre módulos y globales.
Creo que los carteles anteriores han cubierto bien algunas de las distinciones básicas. (El uso de npm de dependencias anidadas es de hecho muy útil para administrar aplicaciones grandes y complejas, aunque no creo que sea la distinción más importante).
Sin embargo, me sorprende que nadie haya explicado explícitamente una de las distinciones más fundamentales entre Bower y npm. Si lee las respuestas anteriores, verá la palabra 'módulos' utilizada a menudo en el contexto de npm. Pero se menciona casualmente, como si pudiera ser una diferencia de sintaxis.
Pero esta distinción de módulos vs. globales (o módulos vs. 'scripts') es posiblemente la diferencia más importante entre Bower y npm. El enfoque npm de poner todo en módulos requiere que cambie la forma en que escribe Javascript para el navegador, casi seguramente para mejor.
El enfoque de Bower: recursos globales, como <script>etiquetas
En la raíz, Bower se trata de cargar archivos de script simples. Independientemente de lo que contengan esos archivos de script, Bower los cargará. Lo que básicamente significa que Bower es como incluir todas sus secuencias de comandos en los viejos <script>en <head>su HTML.
Entonces, el mismo enfoque básico al que estás acostumbrado, pero obtienes algunas buenas comodidades de automatización:
- Solía necesitar incluir dependencias JS en el repositorio de su proyecto (durante el desarrollo) u obtenerlas a través de CDN. Ahora, puede omitir ese peso de descarga adicional en el repositorio, y alguien puede hacer un rápido
bower instally tener instantáneamente lo que necesita, localmente.
- Si una dependencia de Bower especifica sus propias dependencias
bower.json, también se descargarán para usted.
Pero más allá de eso, Bower no cambia la forma en que escribimos JavaScript . Nada de lo que pasa dentro de los archivos cargados por Bower debe cambiar en absoluto. En particular, esto significa que los recursos proporcionados en los scripts cargados por Bower (generalmente, pero no siempre) se definirán como variables globales , disponibles desde cualquier parte del contexto de ejecución del navegador.
El enfoque npm: módulos JS comunes, inyección explícita de dependencias
Todo el código en Node land (y, por lo tanto, todo el código cargado a través de npm) está estructurado como módulos (específicamente, como una implementación del formato de módulo CommonJS , o ahora, como un módulo ES6). Entonces, si usa NPM para manejar las dependencias del lado del navegador (a través de Browserify o alguna otra cosa que haga el mismo trabajo), estructurará su código de la misma manera que Node.
Las personas más inteligentes que yo han abordado la pregunta "¿Por qué módulos?", Pero aquí hay un resumen de la cápsula:
- Cualquier cosa dentro de un módulo tiene un espacio de nombres efectivo , lo que significa que ya no es una variable global, y no puede hacer referencia accidentalmente sin tener la intención de hacerlo.
- Cualquier cosa dentro de un módulo debe inyectarse intencionalmente en un contexto particular (generalmente otro módulo) para poder usarlo
- Esto significa que puede tener múltiples versiones de la misma dependencia externa (lodash, digamos) en varias partes de su aplicación, y no colisionarán / entrarán en conflicto. (Esto sucede sorprendentemente a menudo, porque su propio código quiere usar una versión de una dependencia, pero una de sus dependencias externas especifica otra que está en conflicto. O tiene dos dependencias externas que quieren una versión diferente).
- Debido a que todas las dependencias se inyectan manualmente en un módulo en particular, es muy fácil razonar sobre ellas. Usted sabe a ciencia cierta: "El único código que debo tener en cuenta al trabajar en esto es lo que he elegido inyectar aquí" .
- Debido a que incluso el contenido de los módulos inyectados está encapsulado detrás de la variable a la que lo asigna, y todo el código se ejecuta dentro de un alcance limitado, las sorpresas y las colisiones se vuelven muy improbables. Es mucho, mucho menos probable que algo de una de sus dependencias redefina accidentalmente una variable global sin que se dé cuenta, o que lo haga. ( Puede suceder, pero por lo general tiene que hacer todo lo posible para hacerlo, con algo como
window.variable. El único accidente que aún suele ocurrir es la asignación this.variable, sin darse cuenta de que thisrealmente está windowen el contexto actual).
- Cuando desea probar un módulo individual, puede saber muy fácilmente: ¿exactamente qué más (dependencias) están afectando el código que se ejecuta dentro del módulo? Y, como está inyectando todo explícitamente, puede burlarse fácilmente de esas dependencias.
Para mí, el uso de módulos para código de front-end se reduce a: trabajar en un contexto mucho más estrecho que es más fácil de razonar y probar, y tener una mayor certeza sobre lo que está sucediendo.
Solo lleva unos 30 segundos aprender a usar la sintaxis del módulo CommonJS / Node. Dentro de un archivo JS dado, que va a ser un módulo, primero declara cualquier dependencia externa que desee usar, como esta:
var React = require('react');
Dentro del archivo / módulo, haces lo que normalmente harías y creas algún objeto o función que querrás exponer a usuarios externos, llamándolo tal vez myModule.
Al final de un archivo, exporta lo que quiera compartir con el mundo, así:
module.exports = myModule;
Luego, para usar un flujo de trabajo basado en CommonJS en el navegador, usará herramientas como Browserify para capturar todos esos archivos de módulos individuales, encapsular sus contenidos en tiempo de ejecución e inyectarlos entre sí según sea necesario.
Y, dado que los módulos ES6 (que probablemente transpilarás a ES5 con Babel o similar) están ganando una gran aceptación y funcionan tanto en el navegador como en el Nodo 4.0, también debemos mencionar una buena descripción general de ellos.
Más sobre patrones para trabajar con módulos en este mazo .
EDITAR (febrero de 2017): el hilo de Facebook es un reemplazo / suplemento potencial muy importante para npm en estos días: gestión de paquetes rápida, determinista y fuera de línea que se basa en lo que npm le brinda. Vale la pena echarle un vistazo a cualquier proyecto JS, especialmente porque es muy fácil cambiarlo de entrada / salida.
EDITAR (mayo de 2019) "Bower finalmente ha quedado en desuso . Fin de la historia". (h / t: @DanDascalescu, a continuación, para un resumen resumido).
Y, mientras Yarn todavía está activo , gran parte del impulso cambió a npm una vez que adoptó algunas de las características clave de Yarn.
