Question

Dans votre expérience professionnelle ont haml & SASS avéré être utile? De quelle manière?

Était-ce utile?

La solution

Haml est agréable, et je l'utilise beaucoup, mais Sass vaut seul, surtout si vous devez construire des feuilles de style complexes. Par exemple, l'une des pires choses à propos de CSS est de savoir combien de redondance que vous devez faire lorsque vous nommez sélecteurs. En CSS, vous devez faire

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

Avec Sass, vous pouvez simplement imbriquer ces decendants naturellement.

#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

Vous pouvez également utiliser des variables

!border_color = #333

.box
  border = 1px "solid" !border_color

Et vous pouvez utiliser les mathématiques avec eux

!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

Vous pouvez également partager le code

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

.box
 +rounded

Il y a tellement de pouvoir dans ce que vous devez à vous-même de l'apprendre. De plus, le résultat final est CSS simple et peut donc être converti.

Ne pas oublier css2sass qui convertit votre code CSS existant Sass fichiers!

Vous pouvez jouer avec quelques exemples http://rendera.heroku.com/ si vous comme. C'est un site que je construit pour aider les gens à apprendre HTML5 et CSS3 et je le soutien à la fois HAML et SASS là.

De plus, jetez un oeil à StaticMatic (staticmatic.rubyforge.org) pour une façon incroyable de faire du site web statique avec HAML et SASS. Il génère des sites Web que vous pouvez télécharger à des hôtes statiques et dispose d'un système de mise en page et un modèle similaire à Ruby on Rails.

Pour répondre à la question directe que vous avez demandé, par voie de « ça vaut la peine », la réponse est oui. Être en mesure d'utiliser des variables, les choses facilement du groupe par le sélecteur et le partage de codes via des modules complexes rend beaucoup plus facile stylesheets. Construire les feuilles de style ne prend pas longtemps du tout, et vous pouvez utiliser l'excellent cadre de boussole pour aller encore plus loin. Par exemple, vous pouvez utiliser les modules 960.gs ou du Plan directeur pour mélanger ces cadres dans vos feuilles de style existants. De cette façon, vous ne devez pas modifier le balisage de votre code. Ajout 960.gs et son « grid_12 » et « container_12 » des classes à tous de votre balisage pourrait ne pas être possible, mais avec boussole et Sass il est un jeu d'enfant.

Sass rend également plus facile d'avoir plusieurs feuilles de style pour le mode de développement et de générer une seule feuille de style pour la production, améliorant ainsi les performances côté client (moins les appels vers le serveur de la charge de page.)

HAML a ses propres avantages, mais ils ne sont pas aussi visibles que Sass. HAML ne rend incroyablement facile à imbriquer des éléments et déclarer DIVS ... en utilisant même 960.gs régulièrement par exemple, est facile avec HAML:

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

Beaucoup moins de frappe. Et si vous décidez besoin d'ajouter une enveloppe autour de tout cela pour une raison quelconque, en retrait juste la chose sous une nouvelle étiquette.

L'espoir qui aide. I <3 Sass.

Autres conseils

Mon site actuel a plus de 800 fichiers HAML et 150 fichiers Sass, et laissez-moi vous dire que cela a énormément aidé mon développement.

Le plus grand avantage est en termes de développement rapide:. La création de fichiers Haml / Sass nécessite beaucoup moins de frappe, vous pouvez donc clouer votre logique de présentation avec beaucoup moins de frappes que si vous faisiez un modèle de erb

Je trouve aussi les fichiers Haml beaucoup plus facile à lire, et moins sujette aux erreurs.

YMMV, mais je l'ai atteint le point de ne pas utiliser Haml se sent comme une corvée.

TL; DR - Bien que populaire, je préfère ne pas utiliser HAML ou SASS, mais j'aime SCSS

.

Il semble que le consensus général sur HAML est massivement en faveur de celui-ci, mais personnellement je ne prends pas soin.

Si mon intention est de générer le code HTML, alors je préfère la langue de modèle pour être aussi proche que possible HTML. Cela évite d'avoir à apprendre une autre couche d'indirection qui ajoute la possibilité de confusion et d'erreurs ainsi que les frais généraux encourir cognitif.

Je trouve les contraintes que les lieux HAML sur mon utilisation préférée des espaces pour la lisibilité et l'emballage de ligne à onéreux et entraîne souvent une syntaxe qui peut être difficile à lire.

Récemment, je rencontré une erreur subtile dans un modèle HAML qui aurait été immédiatement évident si le modèle était ERB, par exemple:

 .table
   .thead
   .tr
   .tr

Les lignes de la table sont pas dans la balise THEAD, ce qui est tout à fait valable HAML, mais incorrect par rapport à la structure HTML prévue. Alors que la page semble rendre correctement, un sélecteur CSS a échoué, ce qui a entraîné une défaillance silencieuse de code JavaScript.

Je suis sûr que ce genre d'erreur serait évident pour la plupart des utilisateurs HAML, comme le montre l'isolement, mais dans le contexte d'un modèle plus grand, il peut être difficile à repérer; en particulier à un développeur de nouveau à HAML.

Par contre, si cela ERB ou HTML:

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

A mes yeux, l'erreur dans la structure est beaucoup plus facile à repérer en raison de la façon dont ERB et HTML sont presque toujours en retrait.

Après avoir passé près de deux décennies d'écriture HTML, je dois admettre que j'ai une certaine fierté par écrit bien formé HTML et je ne vois aucune raison d'apprendre une autre façon de représenter et d'apprendre tous les nouveaux modèles visuels nécessaires pour repérer les erreurs .

D'autre part, je aime beaucoup SCSS (par opposition à SASS) parce SCSS est essentiellement une surcouche de CSS. Il n'ajoute une toute nouvelle couche de indirection que je dois traduire mentalement. Il ne fait qu'ajouter un changement modeste dans la syntaxe qui fournit une représentation plus concise (et SEC) des CSS que je trouve très facile à lire et à comprendre.

En effet, je préfère ne pas utiliser pour une langue qui applique une syntaxe stricte en ce qui concerne la façon dont je le retrait ou la ligne envelopper mon code tel que python. Ou les langues qui servent seulement comme une couche d'indirection sur le dessus d'une langue sous-jacente comme coffeescript.

Je ne dis pas que je crois abstraction et indirection sont mauvaises dans les langages de programmation; seulement que je préfère ne pas les utiliser en ce qui concerne les langues spécifiques abordées ici.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top