Los que no ven ninguna utilidad para pre-procesadores, como Sass utilizan a menudo la argumentación de "código malo". Se crean selectores demasiado específicos debido a sprites de enormes anidaciones, y odian la manera en que Sass aplica un enfoque arquitectónico que no funciona. Y todo es cierto, Si eres un mal desarrollador! Ya sabes, aquellos que hacen a mano selectores muy específicos, sprites de 15MB y no saben cómo estructurar limpiamente un proyecto.
Contrarrestando los argumentos en contra de Sass
Con este artículo voy a tratar de desacreditar los argumentos contra el uso de Sass que crean miedo, incertidumbre y duda. Creo que estos argumentos son un error y son utilizados por aquellos que no tienen experiencia real con pre-procesadores o han trabajado con personas que no "lo entienden". Estoy seguro de que puedo convertir cualquier CSS por ahí para Sass, utilizando sustancialmente una cantidad menor de caracteres, manteniendo la misma potencia exacta. Cualquiera que sea Sass compila depende de usted. Ahora, adelante!
"Pistas de selección excesiva producto del anidamiento"
El exceso de anidación que hacemos. Hay una solución muy elegante para esto: no lo hagas.!! Mario ha escrito un excelente artículo acerca de la regla de la incepción en thesassway.
Entiendo que es fácil caer presa del exceso de anidación, e incluso 37signals lo hace. La regla básica es: no trate de imitar su estructura HTML en el Sass. Puede parecer muy útil al principio, pero al final se obtendrá un código no-reusable debido a la extrema especificidad de los selectores. Usted va a terminar de copiar/pegar trozos de Sass y provocar duplicación de código. Mantenga los selectores de poca profundidad.
"Los Mixins agrandan el CSS mediante la repetición de código"
Lo pueden hacer. Cuando un mixin cuenta con cinco líneas de código, incluyendo esto en tu Sass diez veces dará lugar a 50 líneas de CSS. En la mayoría de los casos usted no quiere eso. Mi regla de oro es: me huele a mixins sin argumentos. Cuando el valor de retorno de su mixin depende de argumentos que se pasan a la misma, se debe generar una salida diferente con cada uso. Para un mixin que devuelve el ancho basado a través de un diseño de cuadrícula basado por ejemplo en un número de columnas, tiene mucho sentido.
Para muchos otros usos, la directiva @extend puede ser una mejor opción (siempre y cuando usted lea el siguiente párrafo).
"Ampliar la Directiva crea un montón de selectores feos"
Pregúntese si su CSS compilado está destinado a ser legible por humanos o de lectura mecánica. Si usted trabaja en Sass, pero reconoce que el CSS resultante será editado mano, intentaria evitar extender los selectores. Cuando se utiliza @extend dos veces en un solo selector, habrá código relacionado con él en tres lugares en el CSS (asumiendo que no están jerarquizando el extends).
Para un navegador sin embargo, la forma en que se formatea el código no importa realmente, por lo que minificar su código es una buena práctica. Un codigo bonito es menos importante que el performance del código y extender sus selectores puede definitivamente conducir a DRY'er su código como el uso mixins. Por otro lado, no hay que exagerar. Si usted se encuentra la ampliación de su Clase clearfix veinte veces, puede considerar añadir esto a su HTML (o aprender cómo
nfuncionan los floats). Use el sentido común.
"No se puede utilizar Sass en un Enfoque OOCSS (o cualquier otra arquitectura)"
Claro que puedes. Si desea utilizar nombres de las clases en todos los elementos en el código HTML y define (extremos) selectores de poca profundidad en el CSS, Sass tiene tu respaldo. Si usted quiere tomar un enfoque anidado, donde sólo se establece un nombre de clase de un elemento contenedor y utilizar selectores de descendientes en el CSS, Sass es una buena opción. Incluso se puede simplemente tomar su CSS hecho a mano, cambiarle el nombre a SCSS y sólo utilizar esas características en Sass y Compass que alegrara su día. Sass no tiene nada que ver con su enfoque arquitectónico. Dile que lo que debe hacer, y lo hará.
Conoce tu compilador.
No es necesario conocer los detalles internos de Sass, solo saber lo que se hará en el código. Tienes que abrir el CSS procesado de vez en cuando y ver lo que parece. No es ciencia de cohetes para aprender a predecir lo que el código Sass compilará. Es una buena cosa que pensar "¿cómo voy a hacer esto en plano al 'CSS" al escribir Sass?". Por lo menos usted sabrá si un determinado uso de @extend añade un trillon selectores a tu CSS y tomar una decisión informada en cuanto a usarlo o no.
Sass es solo una herramienta.
Así como no se puede esperar que todo el que tiene un martillo sea un maestro carpintero, Sass no automágicamente te convertirá en un gran desarrollador de front-end. Al final, Sass es "sólo" una herramienta de gran alcance. Y al tomar la responsabilidad en este gran poder, que le ayudará a escribir y mantener su estilo de forma fácil, independientemente del enfoque que usted tome. Conoce lo que estás haciendo y te irá bien.!!
Artículo original en inglés en: Sass doesn't create bad code. Bad coder do.
No hay comentarios:
Publicar un comentario