Breaking

Post Top Ad

Your Ad Spot

jueves, 30 de mayo de 2019

¿Cuál es la diferencia entre Sass y SCSS?

Esta es la versión actualizada de un artículo publicado originalmente el 28 de abril de 2014.
He escrito mucho sobre Sass, pero algunos comentarios me dejaron en claro que no todos saben exactamente a qué se refiere Sass. Aquí hay un poco de claridad:
Cuando hablamos de Sass , generalmente nos referimos al preprocesador y al lenguaje en general. Diremos, por ejemplo, "estamos usando Sass" o "aquí hay una mezcla de Sass". Mientras tanto, Sass (el preprocesador) permite dos sintaxis diferentes:
  • Sass , también conocida como la sintaxis indentada.
  • SCSS , una sintaxis similar a CSS

Historia de Sass

Inicialmente, Sass era parte de otro preprocesador llamado Haml , diseñado y escrito por desarrolladores de Ruby. Debido a eso, las hojas de estilo Sass utilizaban una sintaxis similar a Ruby sin llaves, sin punto y punto y con una sangría estricta, como esta:
// Variable
!primary-color= hotpink

// Mixin
=border-radius(!radius)
  -webkit-border-radius= !radius
  -moz-border-radius= !radius
  border-radius= !radius

.my-element
  color= !primary-color
  width= 100%
  overflow= hidden

.my-other-element
  +border-radius(5px)
Como puede ver, este es un gran cambio en comparación con el CSS normal. Incluso si eres un usuario de Sass (el preprocesador), puedes ver que esto es bastante diferente de lo que estamos acostumbrados. El signo variable es !y no $, el signo de asignación es =y no :Bastante raro.
Pero así es como se veía Sass hasta que llegó la versión 3.0 en mayo de 2010, introduciendo una nueva sintaxis llamada SCSS para Sassy CSS . Esta sintaxis apuntaba a cerrar la brecha entre Sass y CSS al proporcionar una sintaxis compatible con CSS.
// Variable
$primary-color: hotpink;

// Mixin
@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
  -moz-border-radius: $radius;
  border-radius: $radius;
}

.my-element {
  color: $primary-color;
  width: 100%;
  overflow: hidden;
}

.my-other-element {
  @include border-radius(5px);
}
SCSS está definitivamente más cerca de CSS que Sass. Dicho esto, los mantenedores de Sass también han trabajado para acercar ambas sintaxis entre sí moviendo !(signo variable) y =(signo de asignación) de la sintaxis con sangría hacia $:desde el SCSS.
Ahora, al iniciar un nuevo proyecto, puede preguntarse qué sintaxis debe usar. Permítame iluminar el camino y explicar los pros y los contras de cada sintaxis.

Pros para Sass Indented Syntax

Si bien esta sintaxis puede parecer rara, tiene algunos puntos interesantes. En primer lugar, es más corto y más fácil de escribir . No más llaves y punto y coma, no necesitas todas esas cosas. ¡Aun mejor! No es necesario @mixin@include, cuando un solo personaje es suficiente: =+.
Además, la sintaxis de Sass impone estándares de codificación limpios al basarse en la sangría. Como es probable que una sangría incorrecta rompa toda la .sasshoja de estilos, se asegura de que el código esté limpio y bien formateado en todo momento. Hay una forma de escribir el código Sass: la buena manera.
¡Pero cuidado! Sangrar significa algo en Sass. Al sangrar un selector, significa que está anidado en el selector anterior. Por ejemplo:
.element-a
  color: hotpink

    .element-b
      float: left
... generará el siguiente CSS:
.element-a {
  color: hotpink;
}

.element-a .element-b {
  float: left;
}
El simple hecho de empujar .element-bun nivel hacia la derecha significa que es un problema de .element-a, cambiar el CSS resultante. ¡Ten mucho cuidado con tu sangría!
Dejando de lado, creo que la sintaxis basada en sangría probablemente se adapte a un equipo de Ruby / Python más que a un equipo de PHP / Java (aunque esto es discutible, y me encantaría escuchar opiniones contrarias).

Pros para la sintaxis de SCSS

Para empezar, es totalmente compatible con CSS . Esto significa que puede cambiar el nombre de un archivo CSS .scsssolo funcionará . Hacer que SCSS sea totalmente compatible con CSS siempre ha sido una prioridad para los mantenedores de Sass desde que se lanzó SCSS, y esto es un gran problema en mi opinión. Además, intentan mantenerse lo más cerca posible de lo que podría convertirse en una sintaxis CSS válida en el futuro (por lo tanto @directives).
Debido a que SCSS es compatible con CSS, significa que hay poca o ninguna curva de aprendizaje . La sintaxis ya es conocida: después de todo, es solo CSS con algunos extras. Esto es importante cuando se trabaja con desarrolladores sin experiencia: podrán comenzar a codificar rápidamente sin saber lo primero acerca de Sass.
Además, es más fácil de leer porque en realidad tiene sentido. Cuando lees @mixin, sabes que es una declaración mixta; Cuando ves @include, estás llamando a un mixin. No hace ningún atajo, y todo tiene sentido cuando se lee en voz alta.
Además, la mayoría de las herramientas, complementos y demostraciones existentes para Sass se desarrollan utilizando la sintaxis SCSS. A medida que pasa el tiempo, esta sintaxis se está volviendo preeminente y la opción predeterminada, principalmente por las razones anteriores.

Pensamientos finales

La elección depende de usted, pero a menos que tenga realmente buenas razones para codificar utilizando la sintaxis con sangría, le sugiero encarecidamente que use SCSS sobre Sass. No solo es más simple, sino que también es más conveniente.
Una vez probé la sintaxis con sangría y me gustó. Me gustó lo corto y fácil que era. En realidad, estaba a punto de trasladar una base de código completa a Sass en el trabajo antes de cambiar de opinión en el último minuto. Agradezco a mi pasado por detener ese movimiento, porque hubiera sido muy difícil trabajar con varias de nuestras herramientas si hubiéramos usado la sintaxis con sangría.
Además, tenga en cuenta que Sass nunca está en mayúsculas, no importa si está hablando sobre el idioma o la sintaxis. Mientras tanto, SCSS siempre está en mayúsculas. ¿Necesitas un recordatorio? SassnotSASS.com al rescate!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas