erb, haml ou slim: lequel proposez-vous? Et pourquoi? [fermé]


103

J'apprends Rails et j'ai vu ces modèles de moteurs. Je n'ai aucune expérience avec eux (seulement erb).

Mais comme je suis débutant, je suis vraiment confus. Lequel proposez-vous et pourquoi? Erb, Haml ou Slim? Veuillez indiquer la raison pour laquelle vous préférez l'un aux autres. Et si vous avez d'autres recommandations, veuillez nous en informer.

EDIT: Je ne cherche PAS un gagnant ici. Je veux juste connaître vos opinions à leur sujet, leur syntaxe, leur rapidité d'exécution, etc.


7
La réponse courte est, en tant que débutant, utilisez ERB.
Scott Schulthess


Bien que ce ne soit pas un moteur de modèle, vous voudrez peut-être vous pencher sur la gemme dom que j'ai développée. Il vous permet d'écrire sans problème des codes HTML en tant que Ruby.
sawa

15
Cette question «non constructive» m'a été extrêmement utile. Merci de l'avoir demandé, même si les mods pour une raison quelconque ne pensent pas que cela convient. C'était l'un des meilleurs hits de Google et les nombreuses réponses ici m'ont aidé à prendre ma décision.
Andy Baird

2
c'est toujours le résultat Google n ° 1 pour 'rails html erb'
Orwellophile

Réponses:


67

ERB est bon principalement si vous avez un concepteur Web qui travaillera sur du HTML brut et ne connaît ni haml ni slim. De cette façon, il peut écrire du HTML et vous pouvez incorporer la logique ruby ​​avec les balises appropriées.

Si vous travaillez à la fois sur la logique HTML et ruby, ou si votre concepteur est prêt à apprendre quelque chose de nouveau (comme HAML), je choisirais HAML. Il est beaucoup plus compatible avec les rubis, réduit le nombre de caractères de beaucoup et beaucoup plus lisible que ERB.

Par exemple (tiré du site officiel de HAML ):

Dans ERB, votre point de vue ressemblera à ceci:

<div id="profile">
  <div class="left column">
    <div id="date"><%= print_date %></div>
    <div id="address"><%= current_user.address %></div>
  </div>
  <div class="right column">
    <div id="email"><%= current_user.email %></div>
    <div id="bio"><%= current_user.bio %></div>
  </div>
</div>

Dans HAML, cela ressemblera à ceci:

#profile
  .left.column
    #date= print_date
    #address= current_user.address
  .right.column
    #email= current_user.email
    #bio= current_user.bio

Beaucoup plus propre!

En ce qui concerne la différence entre HAML et SLIM - je n'ai jamais vraiment travaillé avec SLIM mais je suppose que c'est une question de goût - jetez un œil aux deux syntaxes et décidez de celle qui vous convient le mieux. Je ne pense pas qu'il y ait un gagnant définitif entre ces deux (HAML / SLIM).


Lisez-le - la dernière phrase sur le gagnant définitif concernait HAML et SLIM (correctement édité).
Erez Rabih

1
Oui, +1 pour cela, même si Haml & Slim retirent tous les déchets du HTML et veulent une meilleure phrase, totalement génial, de nombreuses personnes uniquement HTML ne peuvent tout simplement pas comprendre (ou ne sont pas pas de codeurs à main en premier lieu, ou compter sur des extraits de code et des pâtes à copier.)
ocodo

8
@ErezRabih en fait il y a une différence majeure entre HAML et SLIM. Slim est beaucoup plus rapide que HAML. Il a également une syntaxe plus propre, et vous permet d'écrire des attributs HTML plus propre: a href="foo".
Mohamad

87

Deux grands avantages de l'utilisation de slim sur haml:

  1. Slim est actuellement environ huit fois plus rapide que le haml.

  2. Slim prend en charge le streaming HTTP, contrairement à HAML.

  3. Slim a une syntaxe plus naturelle: a href="foo.html"


3
Avez-vous une source fiable pour votre déclaration sur la vitesse de Slim vs Haml? Je lis beaucoup à ce sujet partout, mais sauf sur la page GitHub de Slim, je ne trouve pas beaucoup d'informations prouvables à ce sujet.
Joshua Muheim

4
@JoshuaMuheim Slim est livré avec un code de référence que vous pouvez modifier / tester sur votre propre machine: github.com/stonean/slim#testing
Gerry

5
+1 Slim prend en charge le streaming HTTP, nous rencontrons des problèmes avec notre passerelle de paiement et Heroku, il semble que le streaming HTTP soit un moyen de résoudre ce problème, mais comme notre application fonctionne avec HAML, cette solution n'est plus une option
Flov

1
@DamianNowak Je pense que votre déclaration est trop généralisée. Vous voulez probablement dire que la vitesse ne devrait pas nécessairement être un facteur décisif, étant donné d'autres facteurs. Et si une bibliothèque était suffisamment lente pour devenir un goulot d'étranglement? Je suis sûr que les développeurs en prendraient note. Les développeurs doivent donner du poids à la vitesse, sinon ils ne seraient pas très intelligents, hein?
Kelvin

16
L'optimisation prématurée n'est pas une bonne idée si elle nécessite beaucoup de travail supplémentaire, mais il n'est pas prématuré de simplement choisir une bibliothèque similaire plutôt qu'une autre en raison d'un avantage significatif en termes de performances.
Jamon Holmgren le

35

Du haut de ma tête c'est ce que j'ai trouvé

ERB :

Avantages

  • par défaut hors de la boîte
  • pas dépendant de l'espace blanc
  • la plus basse barrière d'entrée (si elle provient du HTML) comme son HTML avec du code Ruby saupoudré
  • la plupart des lexers d'IDE le lisent par défaut
  • DHH le préfère
  • les anciennes applications l'utilisent probablement toujours

Les inconvénients

  • plus verbeux
  • Les balises content_for dans les helpers et les vues peuvent devenir rapidement incontrôlables
  • content_for tags rend l'imbrication des tags plus difficile car erb ne renvoie que la dernière ligne du bloc. vous devez donc ajouter une chaîne, puis la renvoyer.

HAML

Avantages

  • plus concis. pas de balises de fermeture, s'adapte aux petits écrans
  • structure visuellement plus propre
  • a intégré des helpers (haml_concat, haml_capture) pour utiliser haml dans les méthodes d'aide
  • chaînage de classes
  • beaucoup de sucre syntaxique utile comme # pour les divs ou. pour le chaînage de classes, ou: javascript pour les balises JS

Les inconvénients

  • dépendant des espaces blancs, ce qui entraîne parfois des erreurs difficiles à comprendre
  • les balises complexes ont généralement besoin de recourir au format "haché". (Bien que je pense en fait que c'est un excellent exemple de flexibilité pour quelqu'un qui commence, cela pourrait être pénible.)
  • ajouté comme un bijou (encore une fois probablement un étirement pour mettre cela comme un con)
  • les concepteurs peuvent avoir du mal à ajuster
  • en plus de l'avertissement général sur les espaces blancs ... des erreurs d'espaces simples, par exemple. les tabulations et les espaces pour l'indentation peuvent entraîner des erreurs de production dans les pages que les spécifications / tests normaux ne saisiront pas. Morale: attendez-vous à un besoin accru de tests de vue et n'utilisez peut-être pas le haml pour les vues critiques, à moins que vous ne soyez sûr que vos tests testent le rendu réel de la vue.
  • est plus lent (que erb)
    • mise en garde: c'est du code ruby ​​dont nous parlons si la vitesse est un problème de blocage dans votre application, il existe des alternatives à ruby, par exemple haskell

J'ajouterais que Haml est plus lent en termes de performances que erb en tant que con.
bkunzi01

Ouaip. pour sûr. J'ai ajouté celui-là
ingénieurDave

1
Si vous aimez HAML et que vous êtes préoccupé par les performances, essayez Hamlit. J'ai constaté une nette amélioration de la vitesse de rendu de mes applications presque aussi rapide que celle d'ERB. github.com/k0kubun/hamlit
Jorge Najera T

21

La question pour moi se résume à préférez-vous mettre %avant chaque balise ou |avant chaque nouveau bloc de texte?

Svelte:

 tag(attr= "value")
  | text

Haml:

 %tag{attr: "value"}
   text

Une dernière chose à surveiller: haml suppose un espace blanc entre les nouvelles lignes ( supprimez les espaces dans haml ) tandis que slim ne suppose aucun espace (ajoutez des espaces dans Slim ici et ici )


9
+1. Mais le tube n'est pas nécessaire pour le texte sur la même ligne que la balise. Cela n'est nécessaire que si la première ligne de texte à l'intérieur d'une balise n'est pas sur la même ligne que la balise. Chaque ligne après la première n'a pas besoin du tuyau, à cause de l'indentation.
Kelvin

En fait, j'aime cet aspect de slim, car cela me rend très difficile d'écrire des chaînes non internationalisées.
KonstantinK

définitivement |pour chaque bloc de texte %pour chaque balise. Il y a beaucoup plus de balises que de blocs de texte littéral. Un petit avantage sémantique pour moi avec slim est que tout html littéral brut avec des <>balises utilisées est précédé d'un explicite |. Je préfère "tout est mince à moins |que vous ne le rendiez explicitement littéral avec " over "tout est littéral jusqu'à ce que vous le fassiez hameau avec un %.
ahnbizcad

Je pense que Slim ressemble plus à HTML ( attr="value"), tandis que Haml ressemble plus à Ruby ( {key: "value"}comme Hash).
Franklin Yu

16

https://github.com/scalp42/hamlerbslim - est une référence indépendante qui montre Slim et Erb comme gagnants, en termes de performances (Slim a également tendance à réduire la taille de la sortie HTML.)

Mon opinion personnelle est que dans l'ensemble, Slim et Haml vous feront gagner du temps (== argent) en termes de maintenance, à condition que vous ayez des gens avertis Haml / Slim qui s'occupent de vos points de vue.

Si vous n'avez pas ces personnes, Erb est certainement la voie à suivre, car malgré la meilleure volonté du monde, il y a beaucoup de personnes très bon marché disponibles qui peuvent travailler avec HTML / Erb, mais trouvent Haml / Slim complet mystère.

Le meilleur de tous les cas, formez ces personnes à utiliser Slim ou au moins leur exposez-les, et gardez le nombre de ceux qui «comprennent».

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.