Sass vs. Stylus ¿Quién gana la batalla de sintaxis mínima?

Hoy vamos a enfrentar a dos preprocesadores de CSS cabeza a cabeza. Sin duda, se ha visto mucha discusión acerca de cómo SCSS se compara con MENOS, pero, ¿dónde tiene en cuenta Stylus, el nuevo chico del bloque? ¿Es posible que coincida con la potencia y la versatilidad de SASS?

Nos saltaremos de cabeza en ambas sintaxis y las compararemos una al lado de la otra para ver cuál es más lógica y versátil. También hablaremos sobre las características y le daremos un argumento claro de por qué un preprocesador es más poderoso. Puedes estar tranquilo, no nos vamos a molestar y darte un poco sobre una corbata, ¡habrá un ganador!

Sass, no SCSS

Es necesario abordar un pequeño detalle antes de profundizar en esto. La sintaxis que usaremos hoy es Sass, no SCSS. El último de estos es la forma más nueva, por lo que es probable que sea la persona con la que está más familiarizado.

Sin embargo, en aras de la comparación, Sass está en realidad mucho más cerca de Stylus que su hermano SCSS. Si bien SCSS fue un intento de reiniciar Sass y hacer que la sintaxis sea más parecida a un CSS, Stylus sigue los pasos del lenguaje Sass original en su abandono de la mayoría de las sintaxis estructurales, como los puntos y comas.

Lamentablemente, este no es un artículo sobre los méritos de Sass contra SCSS, por lo que me abstendré de seguir explicándome sobre este tema. Si está buscando una buena discusión sobre este tema, consulte: Sass vs. SCSS: ¿Qué sintaxis es mejor? de The Sass Way. En general, solo tenga en cuenta que Sass y SCSS son en gran medida la misma característica, la única diferencia es cómo los escribe.

Sintaxis basica

Comencemos con una comparación directa de ambas sintaxis en su nivel más básico. Escribiremos la misma declaración en ambos idiomas y veremos dónde se encuentran las diferencias.

Como puedes ver, son casi idénticos. Ninguna de las sintaxis requiere llaves o puntos y comas, lo que por supuesto significa que ambos dependen bastante del espacio en blanco para la compilación adecuada. La gran diferencia que vemos en este punto es con dos puntos: Sass los requiere, Stylus no.

Flexibilidad

Una cosa que siempre he apreciado acerca de LESS y SCSS es que todavía puedo escribir CSS de Vanilla en mi hoja de estilo. Estas sintaxis están tan cerca de CSS que puede escoger y elegir puntos clave para implementar sus características especiales, pero no tiene que volver a entrenar su cerebro para escribir CSS.

Por lo que puedo decir, Sass no tiene esta habilidad, pero Stylus aparentemente la tiene (se muestra aquí). Sin embargo, uso CodeKit para compilar mi Stylus, que no me permite mezclar CSS puro con Sass o Stylus. Si lanzo una línea simple de CSS puro en cualquiera de los dos, el código no se compilará (ambos idiomas tienen informes de error).

Dicho esto, hay un poco de flexibilidad con Stylus y Codekit que no encontrarás en Sass. Por ejemplo, Stylus no requiere el uso de dos puntos o puntos y comas, pero permite que se utilicen ambos. Simplemente no le gustan los corchetes. Sass, por otro lado, requiere dos puntos y no compilará si utiliza puntos y coma.

Ganador de sintaxis básica: Stylus

Si va a utilizar una sintaxis de preprocesador reducida, Stylus es el mejor de los dos en mi opinión. La respuesta simple es que Stylus te permite elegir tu nivel de verbosidad mientras que Sass te obliga a establecer un método establecido.

Honestamente, la razón por la que declaro a Stylus como el ganador aquí podría hacer que lo consideres el perdedor. La sintaxis flexible es una mala palabra con muchos codificadores porque puede llevar a una codificación descuidada e inconsistente. Si va a utilizar Stylus, debe elegir un método de declaración y atenerse a él. No escriba dos líneas de código que solo utilicen puntos y coma, luego cambie a dos puntos y luego vuelva a usar ninguno de los dos.

Anidamiento

Anidar le permite ahorrarse algo de codificación repetitiva al anidar selectores entre sí. Así que cuando un? P? selector está anidado en un? div? selector, el resultado de la compilación será a la vez? div? y? div p ?. Esta funcionalidad es casi idéntica en Stylus y Sass.

Sass en realidad toma el concepto de anidar un paso más allá y le permite ahorrarse la molestia de escribir nombres de propiedades repetitivos. Por ejemplo, considere el siguiente ejemplo. En Stylus, tienes que repetir la fuente? parte, pero Sass permite anidar como un método alternativo.

Ganador: Sass

El hecho simple aquí es que Sass tiene una característica interesante que Stylus no tiene. Nunca lo he usado, y no estoy seguro de que comience ahora, pero puedo ver cómo sería útil, especialmente en casos como alineación de texto, sombra de texto, decoración de texto, etc., donde no existe una alternativa abreviada .

Variables

Uno de los mayores atractivos de los preprocesadores es la inclusión de variables. Muchos desarrolladores de la vieja escuela piensan que esas variables no tienen nada que ver con el CSS, pero muchos otros piensan que las variables son una de las mejores posibilidades para llegar a CSS. Personalmente, encuentro que las variables CSS son inmensamente útiles.

Tanto Stylus como Sass incluyen soporte variable. Esto es lo que cada uno parece usar una variable para declarar el tamaño de fuente en un párrafo.

Una vez más, vemos que la sintaxis de Stylus es un poco más concisa. Observe cómo Sass requiere el uso de un carácter adicional (el signo de dólar) para hacer referencia a las variables. Stylus también toma la ruta de usar un símbolo de igualdad en lugar de dos puntos, lo que debería ser familiar para los desarrolladores de JavaScript.

Ambos idiomas también permiten operaciones de variables, por lo que puede sumar, restar, multiplicar y dividir variables al contenido de su corazón.

Ganador: Dibujar (prefiero la sintaxis de Sass)

Aclaremos esto, si marcamos todo puramente en verbosidad, Stylus seguirá ganando. Es la sintaxis más breve, punto. Pero suponer que más breve es mejor no siempre es correcto.

Curiosamente, a nivel personal, creo que prefiero la forma Sass aquí. La sintaxis de colon solo siente más como CSS. Además, las personas están tan poco acostumbradas a ver las variables en su CSS que los signos de dólar realmente les ayudan a sobresalir. Puedo escanear fácilmente a través de cientos de líneas de Sass y detectar las variables, una tarea que es mucho más difícil con Stylus.

Búsqueda de propiedades

Mientras estamos en el tema de las variables, vale la pena mencionar que Stylus tiene una "Búsqueda de propiedades" única. función que le permite ahorrar algunas de las variables que normalmente tendría que emplear con Sass. Por ejemplo, supongamos que desea establecer el relleno en un elemento en la mitad de su margen. Con Sass, tienes que usar variables para lograr esto (hasta donde puedo decir), pero con Stylus puedes usar el? @? la sintaxis para hacer referencia al valor de otra propiedad dentro del mismo bloque de declaración.

Ganador: Stylus

Sass ni siquiera tiene un equivalente a la función de búsqueda de propiedades, por lo que este no es un concurso. Personalmente, me gusta mucho tener esta habilidad y espero que la gente de Sass considere agregarla.

Mixins & Funciones

A continuación, echaremos un vistazo a los mixins. Estas son variables del tipo de grandes porciones de código en lugar de una sola propiedad o valor. Las mezclas son quizás una de las herramientas más poderosas que tienen los preprocesadores de CSS para ahorrar tiempo y energía. ¡Saber cómo aprovechar adecuadamente los mixins hará que su trabajo sea mucho más fácil!

Este es un ejemplo de la sintaxis de Stylus y Sass en una definición típica de radio de borde. El beneficio aquí es que solo tiene que escribir todos esos prefijos del navegador una vez, y luego permitir que el preprocesador ejecute su magia en cualquier otro lugar donde los implemente.

Una vez más, vemos que Sass requiere un montón de símbolos y sintaxis adicionales, mientras que Stylus mantiene las cosas bastante limpias. También tenga en cuenta que Stylus tiene la opción de utilizar algo llamado "mixins transparentes". donde ni siquiera necesitas usar paréntesis cuando llamas a la mezcla. Parece que solo estoy usando la propiedad predeterminada de radio de borde cuando, de hecho, estoy utilizando mi mezcla.

Las funciones son una construcción similar, solo que normalmente están destinadas a realizar una operación y devolver un valor. Aquí está la sintaxis de la función para cada idioma:

Ganador: Stylus

Después de escribir la mezcla y las funciones con Stylus, y luego volver a Sass, este último parecía mucho más trabajo. La forma del lápiz óptico es realmente sencilla, mientras que Sass te escribe constantemente "@mixin", "@include", "@function" y? @return ?, lo que se siente superfluo.

La carne de la discusión: ¿Cuál es mejor?

No soy el primero en hacer una comparación directa de ejemplos como el anterior, aunque intencionalmente fui un paso más allá que otros al declarar claramente mi preferencia en cada caso.

Honestamente, tanto Sass como Stylus son demasiado grandes para que pueda continuar en este camino de comparación de sintaxis. Hay muchos más casos en los que puedes encontrar que Stylus y Sass son casi idénticos en sus enfoques. Aquí hay algunas características que ambos comparten:

  • Interpolación
  • Herencia del selector a través de @extend
  • Si y si no condicionales de estilo (directivas de control)
  • Funciones de color incorporadas
  • Iteración
  • Directivas de importación

Debería tener una idea de cómo funciona cada idioma ahora, así que avancemos a una discusión pura sobre dónde difieren y por qué es importante. Una cosa en que pensar de inmediato es que Stylus está específicamente diseñado para asociarse con Node.js, por lo que si eres un fanático de Node, este podría ser el camino a seguir.

En su mayor parte, parece que Stylus es la opción más flexible e incluso más poderosa. Hay algunos casos en los que Sass logra un truco que Stylus no puede, pero no he encontrado un "asesino de Stylus". Una característica que me haría decir claramente que Sass es el mejor.

A la inversa, parece que hay un montón de pequeñas cosas que encuentras al excavar en Stylus que extrañas cuando cambias de nuevo a Sass. Ya he mencionado algunos como la función de búsqueda de propiedades, otra interesante son los argumentos. Variable local automática para mixins, que le permite omitir el paso de crear su propia variable para duplicar todos los argumentos de un mixin. También está la función de parámetros restantes que consume los argumentos restantes pasados ​​a una mezcla o función (esta función puede estar en Sass, pero no la he encontrado):

Finalmente, Stylus también quita gran parte del dolor a las consultas de los medios, que son un poco voluminosas y torpes con todos esos soportes. Aquí hay una consulta de medios de impresión Stylus:

¿Qué pasa con SCSS?

Mi preprocesador preferido todos los días es Sass con la sintaxis de SCSS. Hasta que escribí este artículo, no había experimentado mucho con ninguna de las sintaxis simplificadas porque descubrí que me daba un poco de miedo deshacerme de todas las reglas que tenía tan arraigadas en mi cerebro.

Además, me gusta la idea de que algo simplemente se conecte a mi flujo de trabajo CSS actual en lugar de intentar cambiarlo completamente desde cero. Dicho esto, me adapté rápidamente a la forma de hacer las cosas del Stylus y no me importa tanto como pensaba que lo haría. ¡Es muy bueno deshacerse de esos dos puntos!

Digamos que no puedes acostumbrarte o pensar que es una mala práctica usar una sintaxis reducida porque te hará olvidar cómo escribir el CSS correcto, en este caso, ¿SCSS es el camino correcto? Talvez no.Mientras use la línea de comandos o un compilador mejor que CodeKit, Stylus le permite adoptar el estilo "CSS". de sintaxis, lo que significa que puede aprovechar todos los beneficios que se encuentran en Stylus sin aceptar el método mínimo de creación de CSS.

¿Qué pasa con la brújula?

Una pieza absolutamente fundamental de este rompecabezas es Compass, que lleva a Sass a nuevas alturas de maravilla. Obviamente, si dependes de esta herramienta, cambiarte a Stylus será mucho más difícil. Sin embargo, hay un proyecto estrechamente relacionado llamado Nib que intenta llevar algo de calidad de CSS3 similar a Stylus.

Conclusión

Me duele decirlo, pero Stylus realmente parece tener la ventaja en muchos aspectos. Tiene el beneficio de aprender y mejorar lo que se hizo con Sass, y sale mejor por ello. Dicho esto, probablemente no voy a renunciar a SCSS pronto. Creo en el proyecto Sass y confío en que su adopción generalizada continuará produciendo muchas mejoras. No estoy seguro de tener la misma fe en Stylus.

Deja un comentario abajo y déjanos saber lo que piensas. ¿Qué preprocesador crees que es mejor y por qué? Independientemente de cuál tenga más trucos bajo la manga, ¿cuál usarás a largo plazo?