erb, haml ou slim: qual você sugere? E porque? [fechadas]

103

Estou aprendendo Rails e vi esses motores de template. Não tenho experiência com eles (apenas erb).

Mas como sou iniciante, estou muito confuso. Qual você sugere e por quê? Erb, Haml ou Slim? Informe o motivo de você preferir um em vez dos outros. E se você tiver alguma outra recomendação, entre em contato conosco.

EDIT: NÃO estou procurando um vencedor aqui. Eu só quero ouvir suas opiniões sobre eles, sua sintaxe, velocidade de execução e assim por diante.

Omid Kamangar
fonte
7
A resposta curta é, como um iniciante, use ERB.
Scott Schulthess
Embora não seja um mecanismo de template, você pode querer dar uma olhada na joia dom que desenvolvi. Ele permite que você escreva perfeitamente códigos HTML como Ruby.
sawa
15
Essa pergunta "não construtiva" foi incrivelmente útil para mim. Obrigado por perguntar, mesmo que os mods por qualquer motivo não achem que ele se encaixa. Foi um dos maiores sucessos do Google e as muitas respostas aqui me ajudaram a tomar minha decisão.
Andy Baird
2
ainda é o resultado nº 1 do Google para 'rails html erb'
Orwellophile

Respostas:

67

ERB é bom principalmente se você tiver um web designer que trabalhe em HTML puro e não conhece haml ou slim. Desta forma, ele pode escrever HTML e você pode incorporar a lógica ruby ​​com as tags adequadas.

Se você trabalha com lógica HTML e Ruby, ou se seu designer está pronto para aprender algo novo (como HAML), eu escolheria HAML. É muito mais amigável com o Ruby, reduz a contagem de caracteres em muito e muito mais legível do que o ERB.

Por exemplo (retirado do site oficial do HAML ):

No ERB, sua visualização será semelhante a esta:

<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>

Enquanto estiver em HAML, será semelhante a este:

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

Muito mais limpo!

Quanto à diferença entre HAML e SLIM - eu nunca trabalhei realmente com SLIM, mas acho que é uma questão de gosto - dê uma olhada em ambas as sintaxes e decida qual fica melhor aos seus olhos. Não acho que haja um vencedor definitivo entre os dois (HAML / SLIM).

Erez Rabih
fonte
Leia - a última frase sobre o vencedor definitivo foi sobre HAML e SLIM (editado corretamente).
Erez Rabih
1
Sim, +1 para isso, embora Haml e Slim retirem todo o lixo do HTML e estejam à procura de uma frase melhor, totalmente incrível, muitas pessoas que usam apenas HTML simplesmente não conseguem entender (ou não em primeiro lugar, não use codificadores, nem use fragmentos e massas
copiadas
8
@ErezRabih na verdade, há uma grande diferença entre HAML e SLIM. Slim é muito mais rápido do que HAML. Ele também tem uma sintaxe mais limpa, e permite que você escreva atributos HTML mais limpa: a href="foo".
Mohamad de
87

Duas grandes vantagens de usar slim sobre haml:

  1. Slim é atualmente cerca de oito vezes mais rápido que o haml.

  2. Slim suporta streaming de HTTP, enquanto HAML não.

  3. Slim tem uma sintaxe mais natural: a href="foo.html"

Bart ten Brinke
fonte
3
Você tem uma fonte confiável para sua declaração sobre a velocidade de Slim vs Haml? Eu leio muito sobre isso em todos os lugares, mas exceto na página de Slim no GitHub, não encontro muitas informações prováveis ​​sobre isso.
Joshua Muheim
4
@JoshuaMuheim Slim vem com código de benchmark que você pode modificar / testar em sua própria máquina: github.com/stonean/slim#testing
Gerry
5
+1 Slim suporta streaming HTTP, estamos enfrentando problemas com nosso gateway de pagamento e Heroku, parece que streaming HTTP é uma maneira de resolver este problema, mas como nosso aplicativo roda com HAML esta solução não é mais uma opção
Flov
1
@DamianNowak Acho que sua declaração é generalizada demais. Você provavelmente quer dizer que a velocidade não deve necessariamente ser um fator decisivo, dados outros fatores. Além disso, e se uma biblioteca fosse lenta o suficiente para se tornar um gargalo? Tenho certeza que os desenvolvedores notariam então. Devs tem que dar algum peso a velocidade, ou eles não seria muito inteligente, não é?
Kelvin de
16
A otimização prematura não é uma boa ideia se exigir muito trabalho adicional, mas simplesmente escolher uma biblioteca semelhante em vez de outra devido a um benefício significativo de desempenho não é prematuro.
Jamon Holmgren
35

No topo da minha cabeça, foi isso que eu pensei

ERB :

Prós

  • padrão fora da caixa
  • não depende do espaço em branco
  • menor barreira de entrada (se vindo de HTML) como seu HTML com código Ruby espalhado em
  • a maioria dos lexers do IDE o lê por padrão
  • DHH prefere isso
  • aplicativos legados provavelmente ainda o estão usando

Contras

  • mais prolixo
  • tags content_for em helpers e views podem sair do controle rapidamente
  • tags content_for tornam o aninhamento de tags mais difícil, pois erb retorna apenas a última linha do bloco. então você tem que anexar a uma string e então retornar isso.

HAML

Prós

  • mais conciso. sem tags de fechamento, cabe em telas menores
  • estrutura visualmente mais limpa
  • tem ajudantes embutidos (haml_concat, haml_capture) para utilizar haml em métodos auxiliares
  • encadeamento de classe
  • muitos açúcares sintáticos úteis como # para divs ou. para encadeamento de classes ou: javascript para tags JS

Contras

  • dependente do espaço em branco, o que às vezes causa alguns erros difíceis de descobrir
  • tags complexas geralmente precisam recorrer ao formato "hash". (Embora eu realmente ache que este seja um ótimo exemplo de flexibilidade para quem está começando, pode ser uma dor.)
  • adicionado como uma joia (novamente, provavelmente um trecho para colocar isso como um engano)
  • designers podem ter alguns problemas para ajustar
  • além do aviso geral de espaço em branco ... erros simples de espaço em branco, por exemplo. tabulações e espaços para indentação, podem fazer com que as páginas errem na produção, o que as especificações / testes normais não detectam. Moral: Espere uma necessidade maior de testes de visualização e possivelmente não use haml para visualizações de missão crítica, a menos que você tenha certeza de que seus testes estão testando a renderização real da visualização.
  • é mais lento (do que erb)
    • advertência: este é o código Ruby que estamos falando. Se a velocidade é um problema de bloqueio em seu aplicativo, existem alternativas ao Ruby, por exemplo, haskell
engenheiroDave
fonte
Eu acrescentaria que Haml tem desempenho mais lento do que erb como um golpe.
bkunzi01
Sim. com certeza. Eu adicionei aquele
engineerDave
1
Se você gosta do HAML e está preocupado com o desempenho, experimente o Hamlit. Eu vi uma grande melhoria na velocidade de renderização em meus aplicativos quase tão rápido quanto ERB. github.com/k0kubun/hamlit
Jorge Najera T
21

A questão para mim se resume a: você prefere colocar %antes de cada tag ou |antes de cada novo bloco de texto?

Fino:

 tag(attr= "value")
  | text

Haml:

 %tag{attr: "value"}
   text

Mais uma coisa a se observar: haml assume um espaço em branco entre as novas linhas ( remova os espaços em branco em haml ) enquanto slim não ocupa espaço (Adicione espaços em branco no Slim aqui e aqui )

montrealmike
fonte
9
+1. Mas o tubo não é necessário para texto na mesma linha da tag. Só é necessário se a primeira linha do texto dentro de uma tag não estiver na mesma linha da tag. Cada linha após a primeira não precisa do tubo, por causa do recuo.
Kelvin de
Na verdade, gosto desse aspecto do slim, pois torna ainda mais difícil para mim escrever strings não internacionalizadas.
KonstantinK
definitivamente |para cada bloco de texto %para cada tag. Existem muito mais tags do que blocos de texto literal. Uma pequena, mas semântica vitória para mim com o slim é que qualquer html literal bruto com <>tags usadas é precedido por um explícito |. Eu prefiro "tudo é fino, a menos que você explicitamente torne literal com |" sobre "tudo é literal até que você faça haml com um %.
ahnbizcad
Acho que Slim se parece mais com HTML ( attr="value"), enquanto Haml se parece mais com Ruby ( {key: "value"}como Hash).
Franklin Yu
16

https://github.com/scalp42/hamlerbslim - é um benchmark independente que mostra Slim e Erb como vencedores, em termos de desempenho (slim tende a reduzir o tamanho da saída HTML também).

Minha opinião pessoal é que, no geral, Slim e Haml vão economizar seu tempo (== dinheiro) em termos de manutenção, contanto que você tenha pessoas experientes de Haml / Slim cuidando de suas opiniões.

Se você não tem essas pessoas, Erb é definitivamente o caminho a seguir, porque apesar da melhor vontade do mundo, há muitas pessoas muito baratas disponíveis que podem trabalhar com HTML / Erb, mas encontre Haml / Slim um completo mistério.

Melhor de todos os casos, treine essas pessoas para usar Slim ou, pelo menos, exponha-as a ele, e mantenha os números de quem "entende".

ocodo
fonte