LESS y Sass están orientados a lograr lo mismo, y de hecho son tan similares que puedes confundirlos fácilmente, pero ¿realmente son iguales? ¿Hay algo que uno pueda hacer que el otro no pueda?
En función de cada característica, cada sintaxis tiene una o dos cosas que la otra no. Sin embargo, a pesar del hecho de que inicialmente me atrajo la simplicidad de LESS, a la larga no pude evitar dejarme atrapar por algunas características clave que hacen a Sass realmente poderoso. Síguelo mientras soplo tu mente con algunas de las características sorprendentes y únicas de Sass.
MENOS vs. Sass
Tanto Sass como LESS han existido por bastante tiempo, pero parece que realmente alcanzaron su ritmo en 2011 y ganaron mucha popularidad. Ambos proporcionan excelentes formas de extender CSS para que sean más amigables con los programadores, lo que lleva a un código más lógico y conciso que utiliza mucha menos repetición.
¿Quién es más amable?
Recientemente aquí en Design Shack he estado prestando mucha atención a MENOS. Es cierto que me parece que es la más accesible de las dos opciones. Algunos se opondrán a esta noción hasta que estén de color azul en la cara, pero el hecho simple es que LESS tiene una configuración realmente buena: use un archivo .js simple para las pruebas y compile el código automáticamente con una aplicación fácil de usar: Menos. la aplicación
No importa cuánto pienses que cada desarrollador de CSS debería conocer a Ruby y ser un genio de la Terminal, la realidad es que muchos no encajan en esta descripción y prefieren pasar el día aprendiendo una cosa (MENOS) en lugar de dos (Sass + cómo funcionan las gemas rubí).
Por supuesto, Sass solo requiere un poco de uso de la Terminal que casi cualquier persona pueda manejar, pero te sorprendería saber cuánta gente está rechazada debido a esto.
No tan rapido
Recientemente, sin embargo, este paisaje ha cambiado bastante dramáticamente. Están surgiendo soluciones como CodeKit que hacen que escribir Sass y generar CSS sea tan fácil como usar Sass.
De hecho, CodeKit compila automáticamente los archivos LESS, Sass, Stylus y CoffeeScript. Todo lo que tienes que hacer es colocar la carpeta de tu proyecto y tu trabajo está hecho. ¡Tanto para MENOS ser más amigable!
¿Quién es más poderoso?
Para muchos desarrolladores, el argumento sobre el cual es más fácil de implementar es bastante pequeño, considerando que tanto LESS como Sass son bastante simples de comenzar a usar. El verdadero argumento se reduce al poder: ¿qué lenguaje puede hacer más?
La respuesta no es terriblemente simple. Resulta que tanto LESS como Sass tienen características únicas no compartidas por el otro. Sin embargo, hay que decir que en esta área, Sass realmente saca algunos golpes impresionantes. Echemos un vistazo a dos de mis favoritos: @extender y controlar las estructuras.
Sass @extend
Cada vez que digo algo sobre MENOS, la gente en el campamento de Sass comienza a hablar sobre el comando de extensión de Sass. Resulta que hay una buena razón para esto: en realidad es bastante útil.
La magia detrás de @extend es que te permite diseñar selectores que se combinan con otros selectores y toman prestadas sus propiedades. Digamos que estabas diseñando un blog y querías dos conjuntos de estilos diferentes: uno para un comentario y otro para las respuestas a ese comentario. Su estilo para cada uno se ve casi idéntico, con algunas excepciones:
Alternativamente, solo puedes usar el? .Reply? clase para los diferentes estilos, pero esto requeriría que apliques tanto el? .comment? y? .replicar? Clases a tus divisiones HTML de respuesta. Entonces, ¿cómo podemos mantener nuestro marcado tamaño pero hacer este código menos repetitivo?
Con Sass '@extend, este proceso es muy fácil. Una vez que tenemos nuestro selector inicial en su lugar, simplemente escribimos? @Extend? más el nombre del selector del que queremos robar y todo el código relacionado con el primer selector se aplicará al segundo. Desde aquí podemos entrar y aplicar nuestras excepciones, adiciones, etc.
Tenga en cuenta que estamos utilizando la nueva sintaxis .scss.
Salida CSS
La salida de este comando @extend es agradable y limpia y realmente representa cómo deberíamos haber codificado nuestro CSS en primer lugar. Sass encuentra automáticamente las propiedades compartidas y únicas y establece cada uno en los selectores apropiados.
Entonces, ¿por qué no hacer esto en primer lugar? Gran pregunta De hecho, podrías hacer eso. Sin embargo, la sintaxis de Sass representa un proceso de pensamiento un poco más lineal que es más fácil para algunos envolver su mente.
Tenga en cuenta que este es un ejemplo demasiado simplificado, si estuviera trabajando con un gran proyecto con toneladas de selectores, los beneficios de Sass serían aún más claros.
Ir más lejos
Aumentando su utilidad, el comportamiento de @extend puede manejar un poco de complejidad.Por ejemplo, puede usar múltiples extensiones en un solo selector:
También puedes encadenar @extendos. Esto le permite construir gradualmente capas de complejidad de una manera fácil de entender.
Como puede ver, esto es en realidad un poco más fácil de interpretar que el formulario CSS compilado, que es hermosamente conciso pero puede ser algo confuso.
Para obtener más información sobre Sass @extends, consulte la documentación oficial del sitio web de Sass.
Directivas de Control
El comando Sass @extend es definitivamente un argumento asesino para ir con Sass en MENOS. Es muy útil y ayuda a mantener su complejo CSS brillante limpio, organizado y fácil de leer.
Sin embargo, en la escala loca, @extends puntuación bastante baja. Si realmente desea ver dónde se fue la gente de Sass en algún territorio incompleto, debe consultar las directivas de control, que insertan algunas construcciones de programación serias en CSS.
Todos los fanáticos de CSS puro que no están seguros de Sass en primer lugar definitivamente no les gustará lo que están a punto de ver. Sin embargo, aquellos de nosotros que estamos abiertos a divertirnos con CSS y que nos encanta programar, esto se vuelve realmente interesante.
No para el estilo del día a día
Si echa un vistazo a los ejemplos a continuación y decide que parecen demasiado complicados para usar en sus proyectos, probablemente tenga razón. Vienen con esta advertencia directamente de los desarrolladores de Sass:
? Tenga en cuenta que las directivas de control son una característica avanzada, y no se recomiendan en el curso del estilo del día a día. Existen principalmente para su uso en mixins, particularmente aquellos que forman parte de bibliotecas como Compass, y por lo tanto requieren una flexibilidad sustancial.
Si las declaraciones
Si nunca pensó que vería el día en que se reunieran las declaraciones y el CSS, se equivocó. Sass soporta la funcionalidad básica if / else y la compila en CSS. Por ejemplo, en el siguiente ejemplo, queremos que el color del texto sea negro en todos los casos, excepto en aquellos en los que el color base ya es negro, luego lo configuramos en blanco.
Entonces, digamos que usamos este fragmento de código en alguna plantilla que hemos configurado en otro lugar e importamos esa plantilla en nuestro nuevo archivo de proyecto. ¿Si en algún punto establecemos el color base en negro como este?
Nuestro CSS compilado establecerá el color del párrafo en blanco.
Si, por otro lado, la variable de color base se establece en otra cosa?
el color del párrafo se predeterminará automáticamente a negro.
@en bucle
Además de las declaraciones if, Sass soporta bucles. Por ejemplo, digamos que queremos crear cuatro clases de columnas que aumenten gradualmente de ancho. En lugar de escribir cada clase manualmente, podemos ahorrar mucho trabajo simplemente configurando un bucle simple para.
Esta declaración se compilará en el siguiente CSS:
Fíjate cómo usó el? $ I? contador para aumentar el número añadido al nombre de la clase cada vez y luego aumentar el ancho multiplicando el actual? $ i? Valor por diez píxeles.
@while bucle
Muchos lenguajes de programación admiten diferentes estilos de bucles, por lo que Sass hace lo mismo al incluir no solo "para" estructura pero a? tiempo? estructura también. Esta vez, digamos que queremos construir las clases de Grid de 1 Kb usando Sass. Así es como lo harías:
Esta declaración se repite doce veces, creando clases .grid con nombres que aumentan en uno cada vez y establecen esas clases en un ancho que aumenta en 80px cada vez. Este pequeño fragmento de código CSS se compila en este gran fragmento de código:
@cada
La estructura de control final es @each, que le permite enumerar de manera concisa un conjunto de variables para distribuir a lo largo de una gran porción de código. Por ejemplo, digamos que desea crear algunas clases que utilicen diferentes familias de fuentes, podría hacer algo como lo siguiente:
Esto se compilará en el CSS a continuación.El resultado son tres clases separadas que utilizan los tres nombres de fuente que colocamos en la primera línea de arriba.
Una vez más, para leer más sobre las directivas de control, definitivamente debe consultar la documentación oficial. Hay un ejemplo particularmente agradable de @each que usa nombres de imágenes en lugar de fuentes. Es más útil y práctico que mi ejemplo anterior, pero quería ilustrar una posibilidad diferente.
Antes de quejarse?
El argumento obvio contra el uso de estos es que están directamente en violación de mis argumentos para un código fácil de leer. Estos le ahorran tiempo de escritura, pero requieren una interpretación bastante pesada, lo suficiente como para hacer girar la cabeza a veces. Sin embargo, tenga en cuenta que la gente de Sass los recomienda principalmente para su uso en mixins, que a su vez pueden ayudar a simplificar su código debido a su naturaleza reutilizable.
Admito libremente que probablemente es mejor evitar las estructuras de control siempre que sea posible, pero no puedo dejar de entusiasmarme con el hecho de que Sass incluya estas, advertencia o no advertencia. Realmente hablan del poder de la sintaxis y de cuán comprometido está el equipo de Sass para convertirlo en una herramienta de desarrollo web extremadamente avanzada y única.
Conclusión
Esto no es de ninguna manera una discusión exhaustiva de los beneficios de Sass sobre MENOS, es un vistazo a las dos áreas que me parecieron las más impresionantes e interesantes. Tanto las estructuras de control de extensión como las de extensión proporcionan a los desarrolladores algunas herramientas poderosas que simplemente no encontrarás en ningún otro lugar. Del mismo modo, LESS tiene algunos trucos bajo la manga, como los espacios de nombres, que no encontrarás en Sass.
En última instancia, si usas Sass o LESS no debería importar demasiado. Se reduce a una cuestión de opinión y si te gusta uno mejor que el otro, no deberías tener que sentir que es algo de lo que discutir. Si tomo la ruta Sass y usted toma la ruta MENOS, ambos de nuestros sitios web aún deben contener un archivo CSS puro al final (siempre debe compilar antes de cargar). ¿Por qué debería importarme que la ruta que tomaste para llegar allí fuera diferente a la mía? Siempre que su código resultante sea válido y esté bien estructurado, es tan bueno como el mío.
Dicho esto, estoy ansioso por saber qué sintaxis prefieres. En cuanto a mí, estoy bastante cómodo usando cualquiera. Sin embargo, para ser honesto, comencé firmemente en el campamento LESS, pero recientemente me he sentido realmente atraído por el poder que Sass muestra en características como las anteriores.
¿Qué piensas? Con herramientas como CodeKit que hacen que ambas sintaxis sean tan fácilmente accesibles, ¿cuáles son sus razones para usar una sobre la otra?