gruntjs - ¿Por qué separar el proveedor CSS y JS de CSS y JS personalizados en un flujo de trabajo?

gulp bower

Question

He estado tratando de determinar el razonamiento detrás de lo que parece haberse convertido en la práctica estándar en los flujos de trabajo de Front End de separar el proveedor JS y CSS de JS y CSS personalizados. No estoy seguro de cuáles son los beneficios de la desventaja de una solicitud HTTP adicional, parecería más limpio tener solo un archivo CSS y JS en lugar de tener vendor.css, main.css & vendor.js, main.js.

¿Alguien puede arrojar algo de luz sobre esto?

Answer 1

Dependiendo de su situación, esto le permite hacer sus ediciones más bajas en la cascada para que pueda anular los estilos y comportamientos de los vendedores sin deshacerse de su código. Esto es útil para que siempre tenga una versión de trabajo (código de proveedor) a la que pueda volver. En situaciones como trabajar con Wordpress, desarrollar un tema secundario permite actualizar el tema principal sin eliminar las personalizaciones.

Answer 2

El código del proveedor generalmente cambia con menos frecuencia que el código de su aplicación. Por lo tanto, a medida que actualiza su aplicación, el código del proveedor puede permanecer sin cambios y almacenado en caché en el navegador de su usuario.

En el escenario donde el código del proveedor se incluye con el código de la aplicación, el usuario debe descargar todo el código del proveedor cada vez que actualice la aplicación.

La solicitud HTTP adicional del paquete de proveedor por separado se ve mitigada por el hecho de que el usuario descargará menos código en cada actualización de la aplicación.

Answer 3

Puedo pensar en dos razones.

1. Hospedaje de código de proveedor por separado de su código (por ejemplo, Bibliotecas hospedadas por Google )
2. Separación de inquietudes: el código del proveedor puede ser grande y se actualiza independientemente de su código personalizado. Mantener su código en un archivo separado evita la necesidad de poner código de proveedor en su control de origen, facilita navegar su código, facilita la actualización a un nuevo código de proveedor, ya que sabe con certeza que el código del proveedor no ha sido modificado.

Especialmente desde que etiquetó la pregunta con grunt , el usuario final puede que nunca vea este cambio, ya que puede fusionar estilos / scripts de proveedores y usuarios durante la compilación.

Sin embargo, si el código de proveedor es grande y no se actualiza con frecuencia, se obtiene un beneficio de almacenamiento en caché al tener un archivo de proveedor grande que rara vez cambia, acompañado de un pequeño y rápido archivo de código personalizado modificado. Para sitios grandes que no usan un CDN (con suerte, no el suyo), el impacto puede ser notable.

Answer 4

Varias respuestas ya abordaron esto, pero lo haré muy específico:

1. El código del proveedor puede cambiar más o menos frecuentemente que tu código. Si el código del proveedor cambia con más frecuencia, por ejemplo, para corregir errores, le conviene usar las versiones más nuevas y tener un mejor sitio web en general. Si el código del proveedor cambia MENOS con frecuencia que tu código, es posible que desees cambiar tu código sin tocar las cosas de trabajo.

2. El código del proveedor a menudo se aloja en CDN, por ejemplo, https://cdnjs.com/#q=ajax o https://developers.google.com/speed/libraries/. Estas son cargas RÁPIDAS. Tampoco cambian, por lo que el usuario puede confiar en los archivos almacenados en caché y, por lo tanto, su sitio web se cargará más rápido.

3. En general, es mejor realizar cambios iterativos en el código. También es más fácil administrar código, especialmente con control de fuente cuando cosas específicas están cambiando. No es necesario intercambiar archivos grandes cuando no han cambiado. Mantener las cosas separadas hace que sea más fácil hacer cambios incrementales, especialmente si las dos cosas tienen diferentes velocidades de cambio.