erb, haml ou slim: lequel conseillez-vous? Et pourquoi?

Je suis en train d'apprendre les Rails et j'ai vu ces moteurs de template. Je n'ai aucune expérience avec eux (seulement erb).

Mais comme je suis un débutant, je suis vraiment confus. Lequel conseillez-vous et pourquoi? Erb, Haml ou Slim? Parlez-en à votre raison pour préférer l'une sur les autres. Et si vous avez d'autres recommandations, s'il vous plaît laissez-nous savoir.

EDIT:
Je ne suis PAS à la recherche d'un gagnant ici. Je veux juste entendre vos opinions à leur sujet, leur syntaxe, la vitesse d'exécution, et ainsi de suite.

La réponse courte est, en tant que débutant, ERB.
sephinrothcn.wordpress.com/2014/04/14/...
Bien que n'étant pas un moteur de template, vous voudrez peut-être chercher sur le dom gem que j'ai développé. Il vous permet de vous sans faille écrire du code HTML de Rubis.
Ce "non constructif" question a été incroyablement utile pour moi. Merci pour le demander, même si les mods pour quelque raison que ce soit ne se sentent pas qu'il s'adapte. Il a été l'un des meilleurs résultats google et le nombre de réponses ici m'a aidé à prendre ma décision.
c'est toujours le n ° 1 de résultats sur google pour "rails html erb'

InformationsquelleAutor Omid Kamangar | 2012-07-09

63

ERB est bien surtout si vous avez un concepteur de sites web qui fonctionne sur la plaine HTML et ne sais pas non plus haml ou slim. De cette façon, il peut écrire en HTML et vous pouvez incorporer de rubis logique avec les bonnes balises.

Si vous travaillez sur le code HTML et le code ruby logique, ou votre concepteur est prêt à apprendre quelque chose de nouveau (comme HAML) j'irais pour HAML. Il est beaucoup plus ruby-friendly, réduit char compter beaucoup plus et beaucoup plus lisible que ERB.

Par exemple (pris à partir de officiel HAML site):

Dans ERB votre point de vue, ressemble à 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>
```
Tout en HAML, il 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!

Quant à la différence entre HAML et MINCE je n'ai jamais vraiment travaillé avec SLIM mais je suppose que c'est une question de goût prendre un coup d'oeil à deux syntaxes et de décider ce qui est mieux dans vos yeux. Je ne pense pas qu'il y est un vainqueur définitif entre ces deux (HAML/SLIM).
- Lire la modifier s'il vous plaît.
- Lire - la dernière phrase à propos de gagnant définitif était sur le HAML et SLIM (édité correctement).
- Oui, +1 pour cela, même si Haml & Slim retirer tous les déchets de HTML et d'une meilleure expression, totalement foutu génial, beaucoup de HTML-seulement les gens ne peuvent tout simplement pas obtenir leur tête autour de lui (ou ne sont pas handcoders en premier lieu, ou s'appuient sur des extraits de code et copiez-les pâtes.)
- en fait il existe une différence majeure entre HAML et MINCE. Slim est beaucoup plus rapide que HAML. Il dispose également d'un nettoyeur de syntaxe, et vous permet d'écrire des attributs HTML plus propre: a href="foo".
InformationsquelleAutor Erez Rabih
81

Deux gros avantages de l'utilisation de slim sur haml:
1. Slim est actuellement d'environ huit fois plus rapide que haml.
2. Slim prend en charge le streaming HTTP, tout en HAML ne le fait pas.
3. Slim a un son plus naturel syntaxe: a href="foo.html"
- Avez-vous une source fiable pour votre déclaration au sujet de la vitesse de Slim vs Haml? J'ai lu beaucoup de choses sur ce partout, mais sauf sur Slim de la page GitHub je ne trouve pas beaucoup de preuve de l'information à ce sujet.
- Slim est livré avec un test de code que vous pouvez modifier/test sur votre propre machine: github.com/stonean/slim#testing
- +1 Slim prend en charge le streaming HTTP, nous rencontrez des problèmes avec notre Passerelle de paiement et Heroku, il semble que le streaming HTTP est un moyen de résoudre ce problème, mais que notre application fonctionne avec HAML cette solution n'est pas une option plus
- Je pense que votre déclaration est de plus en plus généralisée. Tu veux sans doute dire la vitesse ne doit pas nécessairement être un facteur décisif, compte tenu d'autres facteurs. Aussi, si une bibliothèque a été suffisamment lente pour devenir un goulot d'étranglement? Je suis sûr que les devs pourraient prendre connaissance ensuite. Les Devs n'ont à donner certains poids à la vitesse, ou qu'ils ne serait pas très intelligent, hein?
- L'optimisation prématurée n'est pas une bonne idée si cela nécessite beaucoup de travail supplémentaire, mais simplement en choisissant une bibliothèque semblable sur l'autre en raison d'un accroissement significatif des performances n'est pas prématurée.
- Pour un projet existant à l'aide de HAML, ils peuvent passer à Faml ou Hamlit. Pour le nouveau projet peut-être Mince est meilleure en raison de la popularité (voir popularité de comparaison).
InformationsquelleAutor Bart ten Brinke
32

Sur le dessus de ma tête, c'est ce que je suis venu avec

ERB:

Pros
- par défaut de la boîte
- pas de blanc espace dépendant
- plus faible barrière d'entrée (si vous venez de HTML) comme ses HTML avec du code Ruby saupoudré dans
- la plupart des IDE lexers lire par défaut
- DHP préfère il
- applications existantes sont sans doute encore à l'utiliser
Contre
- plus détaillé
- content_for balises dans les aides et les vues peuvent sortir de la main rapidement
- content_for étiquettes de fait de l'imbrication des balises plus difficile de l'erb retourne uniquement la dernière ligne du bloc. donc, vous avez à ajouter à une chaîne, puis retour.
HAML

Pros
- plus concis. pas de balise de fermeture, s'inscrit dans les petits écrans
- visuellement plus propre structure
- a construit dans les aides (haml_concat, haml_capture) pour utiliser haml dans les méthodes d'aide
- classe chaînage
- quantité de sucre syntaxique comme # pour les divs ou . pour la classe de chaînage, ou :de javascript (JS tags
Contre
- espaces dépendant de ce qui rend pour une dur erreurs de comprendre à la fois
- complexe tags généralement besoin de recourir à des "hash" format. (Bien que je pense en fait que c'est un excellent exemple de la souplesse à quelqu'un débutant, il peut être une douleur).
- ajouté comme un bijou (encore une fois probablement un tronçon de mettre cela comme un con)
- les concepteurs pourraient avoir quelques difficultés à s'ajuster
- en plus des espaces d'avertissement... de simples espaces d'erreurs par exemple. les tabulations et des espaces pour l'indentation, peut causer des pages à err dans la production normale specs/test ne sera pas attraper. Morale: Attendez plus grand besoin en vue des tests et, éventuellement, ne pas utiliser de haml pour mission de points de vue critiques, sauf si vous êtes sûr que vos tests sont des tests le rendu de la vue.
- est plus lente (de erb)
  - mise en garde: c'est du code ruby 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 performance sage que erb comme un con.
- yup. pour sûr. J'ai ajouté qu'un
- Si vous aimez HAML et vous êtes inquiet au sujet de la performance, essayez Hamlit. J'ai vu une grande amélioration sur la vitesse de rendu sur mes applications presque aussi rapide que l'ERB. github.com/k0kubun/hamlit
InformationsquelleAutor engineerDave
17

Une question me vient à l'préférez-vous mettre % avant chaque balise ou | avant chaque nouveau bloc de texte?

Slim:
```
 tag(attr= "value")
  | text
```
Haml:
```
 %tag{attr: "value"}
   text
```
Une chose de plus à l'affût pour: haml suppose un espace blanc entre les lignes nouvelles ( supprimer les espaces dans haml ), tandis que le slim n'assume pas d'espace (Ajouter des espaces dans des Slim ici et ici)
- +1. Mais le tuyau n'est pas nécessaire pour le texte sur la même ligne que la balise. Il est uniquement nécessaire 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 de la pipe, à cause de l'indentation.
- En fait, j'aime cet aspect de la slim, car elle rend plus difficile pour moi d'écrire non internationalisés cordes.
- certainement | pour chaque bloc de texte sur % pour chaque balise. Il y a beaucoup plus de balises qu'il y a de blocs de texte littéral. Un petit, mais la sémantique de gagner pour moi avec slim est que tout cru littérale html avec <> balises utilisées est précédée par un explicite |. Je préfère "tout est slim, sauf si vous explicitement faire littérale avec |" plus de "tout ce qui est littéral jusqu'à ce que vous faites, il est haml avec un %.
- Je pense que Slim ressemble plus à de l'HTML (attr="value"), tandis que Haml ressemble plus à Ruby ({key: "value"} comme de Hachage).
InformationsquelleAutor montrealmike
15

https://github.com/scalp42/hamlerbslim - est indépendante de référence qui montre Slim et Erb, gagnants, performance sage (slim tend à réduire le code HTML de la taille de sortie trop.)

Mon opinion personnelle est que, dans l'ensemble, Mince et Haml, vous gagnerez du temps (== argent) en termes d'entretien, à condition que vous ayez Haml/Slim savvy personnes à la recherche après votre point de vue.

Si vous n'avez pas ces gens, Erb est certainement le chemin à parcourir, parce que, malgré la meilleure volonté du monde, il y a beaucoup de très peu coûteux de gens qui peuvent travailler avec HTML/Erb, mais trouver Haml/Slim un mystère complet.

Meilleur des cas, de former ces personnes à utiliser Slim ou au moins de les exposer à elle, et de garder le nombre de ceux qui "bien faire".

InformationsquelleAutor ocodo

Vous devez vous connecter pour publier un commentaire.