“¿Qué lenguaje de preprocesador CSS debo elegir?” es un tema candente últimamente. Me han preguntado en persona varias veces y parece que ha surgido un debate en línea cada pocos días. Es bueno que la conversación haya cambiado en gran medida de si el preprocesamiento es una buena idea o no a cuál es el mejor idioma. Hagamos esto.
Respuesta realmente corta: Sass
Respuesta un poco más larga: Sass es mejor en un montón de frentes diferentes, pero si ya estás contento en Less, está bien, al menos te estás haciendo un favor al preprocesar.
Respuesta mucho más larga: sigue leyendo.
La respuesta mucho más larga
La curva de aprendizaje con Ruby y Command Line y lo que sea
La única curva de aprendizaje es la sintaxis. Debe usar una aplicación como CodeKit, LiveReload o Mixture para ver y compilar sus archivos creados. Necesita saber Jack Squat sobre Ruby o la línea de comandos o cualquier otra cosa. Tal vez debería hacerlo, pero no es necesario, por lo que no es un factor aquí. El hecho de que Sass esté en Ruby y Less esté en JavaScript tiene poca importancia para la mayoría de los usuarios potenciales.
Ganador: nadie
Ayudando con CSS3
Con cualquier idioma, puede escribir sus propios mixins para ayudar con los prefijos de los proveedores. No hay ganador allí. ¿Pero sabes cómo no retrocedes y actualizas los prefijos que usas en todos tus proyectos? (No lo hace). Tampoco actualizará su archivo mixins hecho a mano. (Probablemente.)
En Sass, puedes usar Compass y Compass será mantenerse actualizado y, por lo tanto, la situación del prefijo se maneja por usted. El bourbon también es bueno. Habrá algunas idas y venidas sobre cuál de estos proyectos está “por delante”.
En Less, también hay algunas bibliotecas mixin que luchan por ser las mejores. Se ven mucho mejor en estos días que en el pasado. A pesar de sus gráficos de soporte de marketing, no creo que sean tan robustos como las versiones de Sass. Me han hecho comprender en el pasado que el lenguaje de Less en sí mismo no hace posible construir bibliotecas tan sólidas sobre él. Llegaremos a algo de eso a continuación.
En ambos casos, la responsabilidad recae en usted para mantener actualizado el software del preprocesador y estas bibliotecas. También lo encuentro más fácil en Sass en general. Por ejemplo, las actualizaciones de Compass vendrán automáticamente en CodeKit, o usará una Gema que es fácil de actualizar, mientras que Less mixins tendrá que actualizar manualmente un archivo usted mismo.
Ganador: Narrowly Sass
Habilidad del lenguaje: lógica / bucles
Less tiene la capacidad de hacer “mixins protegidos”. Estos son mixins que solo surten efecto when
cierta condición es verdadera. Quizás desee establecer un color de fondo basado en el color del texto actual en un módulo. Si el color del texto es “bastante claro”, probablemente querrá un fondo oscuro. Si es “bastante oscuro”, querrá un fondo claro. Así que tiene un solo mixin dividido en dos partes con estos protectores que aseguran que solo uno de ellos surta efecto.
.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) {
background: black;
}
.set-bg-color (@text-color) when (lightness(@text-color) < 50%) {
background: #ccc;
}
Entonces, cuando lo use, obtendrá el fondo correcto:
.box-1 {
color: #BADA55;
.set-bg-color(#BADA55);
}
Eso está demasiado simplificado, pero es probable que entiendas la idea. Puedes hacer algunas cosas elegantes con él. Less también puede hacer una recursividad autorreferencial donde un mixin puede llamarse a sí mismo con un valor actualizado creando un bucle.
.loop (@index) when (@index > 0) {
.myclass {
z-index: @index;
}
// Call itself
.loopingClass(@index - 1);
}
// Stop loop
.loopingClass (0) {}
// Outputs stuff
.loopingClass (10);
Pero ahí es donde terminan las habilidades de lógica / bucle de Less. Sass tiene operadores lógicos y de bucle reales en el idioma. declaraciones if / then / else, bucles for, bucles while y bucles each. Sin trucos, solo programación adecuada. Si bien los mixins cautelosos son un concepto natural bastante bueno, la solidez del lenguaje va para Sass. Esta solidez del lenguaje es lo que hace posible Compass.
Por ejemplo, Compass tiene un mixin llamado background
. Es tan robusto, que puede pasar casi lo que quiera a esa cosa que producirá lo que necesita. Imágenes, degradados y cualquier combinación de ellos separados por comas, y obtendrá lo que necesita (prefijos de proveedor y todo).
Este código sucinto e inteligible:
.bam {
@include background(
image-url("foo.png"),
linear-gradient(top left, #333, #0c0),
radial-gradient(#c00, #fff 100px)
);
}
Se convierte en este monstruo (que, lamentablemente, es lo que necesitamos para que funcione con la mejor compatibilidad posible con el navegador):
.bam {
background: url('/foo.png'), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff));
background: url('/foo.png'), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px);
background: url('/foo.png'), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px);
background: url('/foo.png'), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px);
background: url('/foo.png'), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px);
background: url('/foo.png'), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px);
}
Ganador: Sass
Bondad del sitio web
Less tiene un sitio web más agradable y utilizable. La documentación de Sass no es terrible. Está completo y puedes encontrar lo que necesitas. Pero cuando compite por la atención de la gente de la interfaz, Less tiene la ventaja. No dudo que esto juega un papel importante en el hecho de que Less gane actualmente la carrera por la popularidad.
Sé que el sitio web de Sass está experimentando una gran reforma y mucha gente increíble está trabajando en él. Sin embargo, me parece que va muy lento.
Ganador: MENOS
El concepto @extend
Digamos que declaras una clase que tiene un poco de estilo. Entonces quieres otra clase en la que quieras hacer casi lo mismo, solo algunas cosas adicionales. En Less probablemente:
.module-b {
.module-a(); /* Copies everything from .module-a down here */
border: 1px solid red;
}
Eso es un “incluir” esencialmente. Un mixin, en ambos idiomas. También podría usar una inclusión para hacer eso Sass, pero es mejor que use @extend
. Con @extend
, los estilos de .module-a
no solo están duplicados en .mobule-b (lo que podría considerarse hinchado), el selector para .module-a se modifica a .module-a, .module-b
en el CSS compilado (que es más eficiente).
.module-a {
/* A bunch of stuff */
}
.module-b {
/* Some unique styling */
@extend .module-a;
}
Se compila en
.module-a, .module-b {
/* A bunch of stuff */
}
.module-b {
/* Some unique styling */
}
¿Mira eso? Reescribe los selectores, lo que es mucho más eficiente.
En Less, cada clase es también una mezcla, enturbia programáticamente las aguas, pero es más fácil de entender al principio.
A partir de Less 1.4, también admite extender. Puede ver algunos ejemplos cuando lo actualizamos en CodePen. Es un poco raro porque no extiende los selectores anidados en la clase original a menos que use un adicional all
palabra clave. Tener la opción de ir de cualquier manera parece que en realidad es más poderoso para mí, pero también desconfío de lo que está sucediendo debajo de las sábanas.
Sass también tiene el poder de extender las clases de “marcadores de posición”. Clases esencialmente invisibles, en el formato de %placeholder { }
. Esto es útil para usar nombres internos que tienen sentido allí, pero que no lo serían como nombres de clases reales.
Ganador: Sass
Manejo variable
Menos usos @, Sass usa $. El signo de dólar no tiene un significado inherente en CSS, mientras que el signo @ sí lo tiene. Es para cosas como declarar @keyframes
o bloques de @media
consultas. Podrías atribuir esto a una preferencia personal y no un gran problema, pero creo que la ventaja aquí es para Sass, que no confunde los conceptos de pie.
Sin embargo, Sass tiene algo de rareza con el alcance de las variables. Si sobrescribe una variable “global” “localmente”, la variable global toma el valor local. Esto se siente un poco extraño.
$color: black;
.scoped {
$color: white;
color: $color;
}
.unscoped {
// LESS = black (global)
// Sass = white (overwritten by local)
color: $color;
}
Escuché que puede ser útil pero no es intuitivo, especialmente si escribe JavaScript.
Ganador: Tossup
Trabajar con consultas de medios
La forma en que la mayoría de nosotros empezamos a trabajar @media
consultas estaba agregando bloques de ellos en la parte inferior de su hoja de estilo principal. Eso funciona, pero conduce a una desconexión mental entre el estilo original y los estilos receptivos. Me gusta:
.some-class {
/* Default styling */
}
/* Hundreds of lines of CSS */
@media (max-width: 800px) {
.some-class {
/* Responsive styles */
}
}
Con Sass o Less, podemos unir esos estilos a través del anidamiento.
.some-class {
/* Default styling */
@media (max-width: 800px) {
/* Responsive styles */
}
}
Puedes ponerte aún más sexy con Sass. Existe una técnica de “responder a” realmente genial (ver código de Chris Eppstein, Ben Schwarz y Jeff Croft) para nombrar / usar puntos de interrupción.
=respond-to($name)
@if $name == small-screen
@media only screen and (min-width: 320px)
@content
@if $name == large-screen
@media only screen and (min-width: 800px)
@content
Puede utilizarlos de forma sucinta y semántica:
.column
width: 25%
+respond-to(small-screen)
width: 100%
Las consultas de medios anidadas son una forma fantástica de trabajar. Se rumorea que Sass 3.3 tendrá más funciones para que esto sea aún más útil, incluida una forma de ampliar el trabajo dentro de las consultas de medios que actualmente es imposible tanto en Less como en Sass.
Ganador: Sass
Matemáticas
En su mayor parte, las matemáticas son similares, pero hay algunas rarezas en la forma en que se manejan las unidades. Por ejemplo, Less asumirá que la primera unidad que usa es la que desea, ignorando otras unidades.
div {
width: 100px + 2em; // == 102px (weird)
}
En Sass, obtienes un error claro: Unidades incompatibles: ’em’ y ‘px’. Supongo que es discutible si es mejor equivocarse o estar equivocado, pero personalmente prefiero tener el error. Especialmente si se trata de variables en lugar de unidades directas y es más difícil de rastrear.
Sass también te permitirá realizar operaciones matemáticas en unidades “desconocidas”, haciéndolo un poco más a prueba de futuro en caso de que aparezca alguna unidad nueva antes de que puedan actualizarse. Menos no lo hace. Hay algunas diferencias más extrañas, como la forma en que Sass maneja la multiplicación de valores que ambos tienen unidades, pero es lo suficientemente esotérico como para que no valga la pena mencionarlo.
Ganador: Narrowly Sass
Desarrollo activo
Voy a actualizar estos números ya que ha pasado suficiente tiempo desde la redacción original de este artículo.
16/05/12 |
12/01/13 |
25/06/13 |
|
---|---|---|---|
Número de problemas abiertos en LESS |
392 |
112 |
142 |
Número de problemas abiertos en Sass |
84 |
83 |
110 |
Solicitudes de extracción pendientes en LESS |
86 |
10 |
5 |
Solicitudes de extracción pendientes en Sass |
3 |
7 |
11 |
Número de confirmaciones en el último mes en MENOS |
11 |
84 |
2 |
Número de confirmaciones en el último mes en Sass |
35 |
14 |
14 |
Nada de eso es una prueba definitiva de que un proyecto sea más activo que el otro, pero es interesante observar las estadísticas. Según tengo entendido, ambos líderes trabajan en los idiomas en el poco tiempo libre que tienen, ya que ambos tienen otros proyectos nuevos importantes en los que están trabajando.
Menos ha sido bastante activo últimamente, pero ahora Sass se ha vuelto mucho más activo también, debido a que un miembro principal se ha concentrado en él directamente.
Ganador: Tossup
Más lectura
- Chris Eppstein: Comparación Sass / LESS
- Jeremy Hixon: Introducción a LESS y comparación con Sass
- Ken Collins: ¿Demasiado MENOS? ¿Debería utilizar Sass?
- Johnathan Croom: Sass vs. LESS vs. Stylus: Shootout de preprocesador