Tenga en cuenta que, a veces, debe elegir entre facilitar la modificación de una solución para un desarrollador de back-end y hacer algo optimizado.
Los sprites CSS que citó son un buen ejemplo. No entiendo cómo alguien puede crear un sitio web cuando la escalabilidad y el rendimiento son importantes y tener enlaces a 100 imágenes, 5 CSS y 15 archivos JavaScript de cada página. Por otro lado, los sprites CSS no son fáciles de mantener, y los pequeños cambios en el diseño pueden requerir mucho trabajo.
Por ejemplo, si tiene tres íconos de estado, uno debajo del otro, y debe agregar un cuarto estado, ¿agrega el cuarto ícono en la parte inferior de la imagen, por separado de los otros tres? ¿O lo agrega después del tercer icono, moviendo todo lo demás hacia abajo para tener un espacio vacío?
Lo mismo viene con la combinación y minificación de archivos CSS y JavaScript. Debe hacerlo para un sitio web de cierta escala, pero requeriría un esfuerzo adicional.
Es exactamente lo mismo para CDN. Debe usarlo para sitios web grandes, pero los cambios serían más difíciles de realizar. Por ejemplo si ha cambiado un archivo CSS, usted tiene que obligar a los navegadores para descargar el nuevo, al modificar el URI para el archivo a cdn.example.com/g.css?r=2
, a continuación cdn.example.com/g.css?r=3
, etc.
Además, "más fácil" es relativo . Vea, por ejemplo, las pautas para escribir código CSS: personalmente, prefiero un estilo por línea, sin espacios en blanco:
#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}
mientras que la mayoría de la gente odiaría esta sintaxis y preferiría la que odio y me resulta difícil de leer (no, no estoy loco):
#TopMenu a
{
text-decoration: none;
color: #fff;
padding: 5px 10px;
float: left;
}
De la misma manera, usar jQuery no significa que facilitará a los desarrolladores back-end modificar sus archivos, porque algunos desarrolladores tienen más experiencia con Prototype u otros marcos.
En todos los casos, una documentación detallada es útil, si el desarrollador quiere leerla (la mayoría de ellos no). También puede facilitar la vida de un desarrollador preguntando con precisión al desarrollador específico cómo prefiere las cosas que se deben hacer, y trabajando codo con codo al principio, mientras construye un marco (por ejemplo, diseñando el flujo de trabajo para minimizar y combina los archivos).