erb, haml o slim: ¿cuál sugieres? ¿Y por qué? [cerrado]

103

Estoy aprendiendo Rails y he visto estos motores de plantilla. No tengo experiencia con ellos (solo erb).

Pero como soy un principiante, estoy realmente confundido. ¿Cuál sugieres y por qué? Erb, Haml o Slim? Indique el motivo por el que prefiere uno sobre los demás. Y si tiene otras recomendaciones, háganoslo saber.

EDITAR: NO estoy buscando un ganador aquí. Solo quiero escuchar sus opiniones sobre ellos, su sintaxis, velocidad de ejecución, etc.

Omid Kamangar
fuente
7
La respuesta corta es, como principiante, use ERB.
Scott Schulthess
Aunque no es un motor de plantillas, es posible que desee ver la gema dom que he desarrollado. Le permite escribir códigos HTML sin problemas como Ruby.
sawa
15
Esta pregunta "no constructiva" fue increíblemente útil para mí. Gracias por preguntar, incluso si los mods, por alguna razón, no sienten que encaja. Fue uno de los principales éxitos de Google y las muchas respuestas aquí me ayudaron a tomar una decisión.
Andy Baird
2
sigue siendo el resultado número 1 de google para 'rails html erb'
Orwellophile

Respuestas:

67

ERB es bueno principalmente si tiene un diseñador web que trabajará en HTML simple y no conoce ni haml ni slim. De esta manera, puede escribir HTML y puede incrustar lógica ruby ​​con las etiquetas adecuadas.

Si trabaja tanto en HTML como en Ruby Logic, o si su diseñador está listo para aprender algo nuevo (como HAML), optaría por HAML. Es mucho más compatible con ruby, reduce el recuento de caracteres en mucho y es mucho más legible que ERB.

Por ejemplo (tomado del sitio oficial de HAML ):

En ERB, su vista se verá así:

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

Mientras esté en HAML, se verá así:

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

¡Mucho más limpio!

En cuanto a la diferencia entre HAML y SLIM, nunca trabajé con SLIM, pero supongo que es una cuestión de gustos, eche un vistazo a ambas sintaxis y decida cuál se ve mejor en sus ojos. No creo que haya un ganador definitivo entre esos dos (HAML / SLIM).

Erez Rabih
fuente
Léalo: la última oración sobre el ganador definitivo fue sobre HAML y SLIM (editada correctamente).
Erez Rabih
1
Sí, +1 para esto, a pesar de que Haml & Slim sacan toda la basura de HTML y están a falta de una frase mejor, totalmente increíble, muchas personas que solo usan HTML simplemente no pueden entenderlo (o no en primer lugar, no use codificadores manuales, o confíe en fragmentos y copia-pasta.)
ocodo
8
@ErezRabih en realidad hay una gran diferencia entre HAML y SLIM. Slim es mucho más rápido que HAML. También tiene una sintaxis más limpia, y le permite escribir atributos HTML de forma más limpia: a href="foo".
Mohamad
87

Dos grandes ventajas de usar slim sobre haml:

  1. Slim es actualmente unas ocho veces más rápido que haml.

  2. Slim admite la transmisión HTTP, mientras que HAML no.

  3. Slim tiene una sintaxis más natural: a href="foo.html"

Bart ten Brinke
fuente
3
¿Tiene una fuente confiable para su declaración sobre la velocidad de Slim vs Haml? Leí mucho sobre esto en todas partes, pero excepto en la página de GitHub de Slim, no encuentro mucha información demostrable al respecto.
Joshua Muheim
4
@JoshuaMuheim Slim viene con un código de referencia que puede modificar / probar en su propia máquina: github.com/stonean/slim#testing
Gerry
5
+1 Slim admite transmisión HTTP, estamos experimentando problemas con nuestra pasarela de pago y Heroku, parece que la transmisión HTTP es una forma de resolver este problema, pero como nuestra aplicación se ejecuta con HAML, esta solución ya no es una opción
Flov
1
@DamianNowak Creo que su declaración es demasiado generalizada. Probablemente quiera decir que la velocidad no debería ser necesariamente un factor decisivo, dados otros factores. Además, ¿y si una biblioteca fuera lo suficientemente lenta como para convertirse en un cuello de botella? Estoy seguro de que los desarrolladores se darían cuenta entonces. Los desarrolladores tienen que darle algo de peso a la velocidad, o no serían muy inteligentes, ¿eh?
Kelvin
16
La optimización prematura no es una buena idea si requiere mucho trabajo adicional, pero no es prematuro elegir simplemente una biblioteca similar sobre otra debido a un beneficio de rendimiento significativo.
Jamon Holmgren
35

Fuera de mi cabeza, esto es lo que se me ocurrió

ERB :

Pros

  • predeterminado fuera de la caja
  • no depende del espacio en blanco
  • barrera de entrada más baja (si proviene de HTML) ya que su HTML con código Ruby esparcido
  • la mayoría de los lexers de IDE lo leen por defecto
  • DHH lo prefiere
  • Es probable que las aplicaciones heredadas todavía lo estén usando

Contras

  • más detallado
  • content_for etiquetas en ayudantes y vistas puede salirse de control rápidamente
  • content_for tags hace que anidar las etiquetas sea más difícil ya que erb solo devuelve la última línea del bloque. por lo que debe agregar a una cadena y luego devolverla.

HAML

Pros

  • más conciso. sin etiquetas de cierre, cabe en pantallas más pequeñas
  • estructura visualmente más limpia
  • ha incorporado ayudantes (haml_concat, haml_capture) para utilizar haml en métodos auxiliares
  • encadenamiento de clases
  • un montón de azúcar sintáctico útil como # para divs o. para el encadenamiento de clases, o: javascript para etiquetas JS

Contras

  • Depende del espacio en blanco, lo que hace que algunos errores difíciles de resolver a veces
  • Las etiquetas complejas generalmente necesitan recurrir al formato "hash". (Aunque en realidad creo que este es un gran ejemplo de flexibilidad para alguien que está comenzando, podría ser una molestia).
  • agregado como una joya (nuevamente, probablemente un tramo para poner esto como una estafa)
  • los diseñadores pueden tener problemas para ajustar
  • además de la advertencia general de espacios en blanco ... errores simples de espacios en blanco, por ejemplo. tabulaciones y espacios para la sangría, pueden hacer que las páginas se equivoquen en producción, lo que las especificaciones / pruebas normales no detectan. Moraleja: espere una mayor necesidad de pruebas de vista y posiblemente no use haml para vistas de misión crítica, a menos que esté seguro de que sus pruebas están probando la representación real de la vista.
  • es más lento (que erb)
    • advertencia: este es el código ruby ​​del que estamos hablando si la velocidad es un problema de bloqueo en su aplicación, hay alternativas a ruby, por ejemplo, haskell
ingeniero Dave
fuente
Agregaría que Haml tiene un rendimiento más lento que erb como una estafa.
bkunzi01
Sip. sin lugar a duda. Agregué ese
ingeniero
1
Si te gusta HAML y te preocupa el rendimiento, prueba Hamlit. He visto una gran mejora en la velocidad de renderizado en mis aplicaciones casi tan rápido como ERB. github.com/k0kubun/hamlit
Jorge Najera T
21

La pregunta para mí se reduce a si prefiere poner %antes de cada etiqueta o| antes de cada nuevo bloque de texto?

Delgado:

 tag(attr= "value")
  | text

Haml:

 %tag{attr: "value"}
   text

Una cosa más a tener en cuenta: haml asume un espacio en blanco entre las nuevas líneas ( elimine los espacios en blanco en haml ) mientras que slim no asume ningún espacio (agregue espacios en blanco en Slim aquí y aquí )

Montreal
fuente
9
+1. Pero la tubería no es necesaria para el texto en la misma línea que la etiqueta. Solo es necesario si la primera línea de texto dentro de una etiqueta no está en la misma línea que la etiqueta. Cada línea después de la primera no necesita la tubería, debido a la sangría.
Kelvin
De hecho, me gusta este aspecto de slim, ya que me dificulta mucho escribir cadenas no internacionalizadas.
KonstantinK
definitivamente |para cada bloque de texto %para cada etiqueta. Hay muchas más etiquetas que bloques de texto literal. Una ganancia pequeña, pero semántica para mí con slim es que cualquier html literal sin formato con <>etiquetas utilizadas está precedido por un explícito |. Prefiero "todo es delgado a menos que lo hagas explícitamente literal con |" sobre "todo es literal hasta que lo hagas haml con a %.
ahnbizcad
Creo que Slim se parece más a HTML ( attr="value"), mientras que Haml se parece más a Ruby ( {key: "value"}a Hash).
Franklin Yu
16

https://github.com/scalp42/hamlerbslim : es un punto de referencia independiente que muestra a Slim y Erb como ganadores, en cuanto al rendimiento (Slim tiende a reducir el tamaño de salida HTML también).

Mi opinión personal es que, en general, Slim y Haml le permitirán ahorrar tiempo (== dinero) en términos de mantenimiento, siempre que tenga personas conocedoras de Haml / Slim cuidando sus puntos de vista.

Si no tiene a esas personas, Erb es definitivamente el camino a seguir, porque a pesar de la mejor voluntad del mundo, hay muchas personas muy económicas disponibles que pueden trabajar con HTML / Erb, pero encuentran Haml / Slim un completo misterio.

Lo mejor de todos los casos es capacitar a estas personas para que utilicen Slim o al menos exponerlas a él, y mantener los números de quienes "lo entienden".

ocodo
fuente