¿Vale la pena aprender haml & sass?

Question

En su experiencia profesional tiene haml & sass demostró ser útil? ¿De qué manera?

Answer 1

Haml es agradable, y lo uso mucho, pero Sass lo vale solo, especialmente si tiene que crear hojas de estilo complejas. Por ejemplo, una de las peores cosas de CSS es la cantidad de redundancia que tiene que hacer al nombrar selectores. En CSS, tiene que hacer

#navbar ul 
#navbar ul li a 
#navbar ul li a:hover 

Con Sass, simplemente puede anidar estas descendencias de forma natural.

#navbar 

    ul 
    margin: 0 
    padding: 0 
    list-style: none 
    width: 100% 

    li 
     margin: 0 
     float: left 
     margin-right: 10px 
     border: 1px solid #000 

     a 
     text-decoration: none 

     &:hover 
      color: red 

También puede utilizar variables

!border_color = #333 

.box 
    border = 1px "solid" !border_color 

Y puede utilizar matemáticas con ellos

!measure = 18px 
!text_size = !measure/1.5 

body 
    font-size = !text_size 
    line-height = !measure 

h1 
    font-size = !measure 
    margin-bottom = !measure 

h2 
    font-size = !measure + 2 

#wrapper 
    width = !measure * 50 

También puede compartir código

=rounded 
    -moz-border-radius: 4px 
    -webkit-border-radius: 4px 
    border-radius: 4px 
    border: 1px solid #000 

.box 
+rounded 

Hay tanto poder en esto que te debes a ti mismo para aprenderlo Además, el resultado final es CSS simple para que pueda convertirse.

¡No se olvide de css2sass que convierte su CSS existente a archivos sass!

Puede jugar con algunos ejemplos en http://rendera.heroku.com/ si lo desea. Es un sitio que construí para ayudar a las personas a aprender HTML5 y CSS3 y allí tengo soporte para HAML y SASS.

Además, eche un vistazo a StaticMatic (staticmatic.rubyforge.org) para obtener una forma increíble de trabajar en sitios web estáticos con HAML y SASS. Genera sitios web que puede cargar a hosts estáticos y tiene un diseño y un sistema de plantillas similar a Ruby on Rails.

Para responder a la pregunta directa que hizo, a modo de "vale la pena", la respuesta es sí. Ser capaz de usar variables, agrupar elementos fácilmente por selector y compartir código a través de módulos hace que las hojas de estilo complejas sean mucho más fáciles. Crear las hojas de estilo no lleva mucho tiempo, y puede usar el excelente marco de Compass para ir más allá. Por ejemplo, puede usar los módulos 960.gs o Blueprint para mezclar esos marcos en sus hojas de estilo existentes. De esta forma, no tiene que cambiar el marcado de su código. Puede que no sea posible agregar 960.gs y sus clases "grid_12" y "container_12" a todas sus marcas, pero con Compass y Sass es muy fácil.

Sass también hace que sea más fácil tener múltiples hojas de estilo para el modo de desarrollo y generar una única hoja de estilo para la producción, mejorando así el rendimiento del cliente (menos llamadas al servidor al cargar la página.)

HAML tiene sus propios beneficios , aunque no son tan notables como Sass. HAML hace que sea increíblemente fácil de elementos nido y declarar DIVS ... usando incluso 960.gs regulares, por ejemplo, es fácil con HAML:

#header.container_12 
    .grid_12 
    %h1 Welcome! 
#middle.container_12 
    .grid_8 
    %h2 Main content 
    .grid_4 
    %h3 Sidebar 

mucho menos escribir. Y si decide que necesita agregar un envoltorio alrededor de todo eso por algún motivo, simplemente sangría todo bajo una nueva etiqueta.

Espero que ayude. I < 3 Sass.

Answer 2

Mi sitio web actual tiene más de 800 archivos Haml y 150 archivos Sass, y déjame decirte que ha ayudado tremendamente a mi desarrollo.

La mayor ventaja es en términos de desarrollo rápido: la creación de archivos Haml/Sass requiere mucho menos tipeo, por lo que puede eliminar su lógica de presentación con menos teclas que si estuviera haciendo una plantilla erb.

También encuentro que los archivos Haml son mucho más fáciles de leer y menos propensos a errores.

YMMV, pero he llegado al punto en que no utilizar Haml es una tarea ardua.

Answer 3

TL; DR - Aunque popular, prefiero no utilizar HAML o SASS, pero me gusta SCSS.

Parece que el consenso general sobre HAML es abrumadoramente a favor de él, pero personalmente no me importa.

Si mi intención es generar HTML, entonces prefiero que el lenguaje de plantilla sea lo más parecido posible a HTML. Esto evita tener que aprender otra capa de indirección que agrega la oportunidad de confusión y error, así como incurrir en gastos generales cognitivos.

Considero que las limitaciones que HAML impone a mi uso preferido de los espacios en blanco para la legibilidad y el ajuste de línea son onerosas y, a menudo, da como resultado una sintaxis que puede ser difícil de leer.

Recientemente me encontré con un sutil error en una plantilla HAML que habría sido evidente de inmediato si la plantilla eran ERB, por ejemplo:

.table 
    .thead 
    .tr 
    .tr 

Las filas de la tabla son no dentro de la etiqueta THEAD, que es perfectamente válido HAML, pero incorrecto con respecto a la estructura HTML prevista. Si bien la página parecía mostrarse correctamente, se produjo un error en el selector de CSS, lo que dio como resultado una falla silenciosa de algunos códigos JavaScript.

Estoy seguro de que este tipo de error sería obvio para la mayoría de los usuarios de HAML, como se muestra de forma aislada, pero en el contexto de una plantilla más grande, puede ser difícil de detectar; especialmente a un desarrollador nuevo en HAML.

Por otro lado, si esto fuera ERB o HTML:

<table> 
    <thead> 
    <tr>...</tr> 
    <tr>...</tr> 

A mis ojos, el error en la estructura es mucho más fácil de detectar debido a la forma de ERB y HTML son casi siempre con sangría.

Después de haber pasado casi dos décadas escribiendo HTML, debo admitir que tengo un cierto orgullo al escribir HTML bien formado y no veo ninguna razón para aprender una forma diferente de representarlo y aprender todos los nuevos patrones visuales necesarios para detectar errores

Por otro lado, me gusta mucho SCSS (a diferencia de SASS) porque SCSS es esencialmente un superconjunto de CSS. No agrega una capa completamente nueva de indirección que necesito traducir mentalmente. Agrega solo un cambio modesto en la sintaxis que proporciona una representación más concisa (y SECA) de CSS que me resulta muy fácil de leer y comprender.

De hecho, prefiero no utilizar en ningún idioma que imponga una sintaxis estricta sobre cómo debo sangrar o alinear mi código como python. O idiomas que solo sirven como una capa indirecta sobre un idioma subyacente como coffeescript.

No digo que crea que la abstracción y la indirección son malas en los lenguajes de programación; solo que prefiero no usarlos con respecto a los idiomas específicos discutidos aquí.