erb, haml o slim: quale suggerisci? E perché? [chiuso]


103

Sto imparando Rails e ho visto questi motori di template. Non ho esperienza con loro (solo erb).

Ma dato che sono un principiante, sono davvero confuso. Quale suggerisci e perché? Erb, Haml o Slim? Per favore, spiega il motivo per cui preferisci uno rispetto agli altri. E se hai altri consigli, faccelo sapere.

EDIT: NON sto cercando un vincitore qui. Voglio solo sentire le vostre opinioni su di loro, sulla loro sintassi, sulla velocità di esecuzione e così via.


7
La risposta breve è che, come principiante, usa ERB.
Scott Schulthess


Sebbene non sia un motore di modelli, potresti voler esaminare la gemma dom che ho sviluppato. Ti permette di scrivere codici HTML in modo invisibile come Ruby.
sawa

15
Questa domanda "non costruttiva" è stata incredibilmente utile per me. Grazie per averlo chiesto, anche se le mod per qualsiasi motivo non ritengono che si adatti. È stato uno dei migliori risultati di Google e le molte risposte qui mi hanno aiutato a prendere la mia decisione.
Andy Baird

2
è ancora il risultato di Google numero 1 per 'rails html erb'
Orwellophile

Risposte:


67

ERB è utile soprattutto se hai un web designer che lavorerà su HTML semplice e non conosce né haml né slim. In questo modo può scrivere HTML e tu puoi incorporare la logica di ruby ​​con i tag appropriati.

Se lavori su HTML e logica ruby, o il tuo designer è pronto per imparare qualcosa di nuovo (come HAML), sceglierei HAML. È molto più adatto al rubino, riduce il numero di caratteri di molto e molto più leggibile di ERB.

Ad esempio (tratto dal sito ufficiale di HAML ):

In ERB la tua vista sarà simile a questa:

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

Mentre in HAML sarà simile a questo:

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

Molto più pulito!

Per quanto riguarda la differenza tra HAML e SLIM - non ho mai lavorato con SLIM ma immagino sia una questione di gusti - dai un'occhiata a entrambe le sintassi e decidi quale ti sembra migliore. Non penso che ci sia un vincitore definitivo tra questi due (HAML / SLIM).


Leggilo: l'ultima frase sul vincitore definitivo riguardava HAML e SLIM (modificati correttamente).
Erez Rabih

1
Sì, +1 per questo, anche se Haml e Slim tirano fuori tutta la spazzatura dall'HTML e vogliono una frase migliore, assolutamente fantastico, molte persone solo HTML semplicemente non riescono a capirlo (o non lo sono Sono codificatori in primo luogo, o affidarsi a snippet e copy-pasta.)
ocodo

8
@ErezRabih in realtà c'è una grande differenza tra HAML e SLIM. Slim è molto più veloce di HAML. Essa ha anche una sintassi più pulito, e consente di scrivere attributi HTML in modo più pulito: a href="foo".
Mohamad

87

Due grandi vantaggi dell'utilizzo di slim su haml:

  1. Slim è attualmente circa otto volte più veloce di haml.

  2. Slim supporta lo streaming HTTP, mentre HAML no.

  3. Slim ha una sintassi più naturale: a href="foo.html"


3
Hai una fonte affidabile per la tua dichiarazione sulla velocità di Slim vs Haml? Ho letto molto su questo ovunque, ma tranne sulla pagina GitHub di Slim non trovo molte informazioni dimostrabili al riguardo.
Joshua Muheim

4
@JoshuaMuheim Slim viene fornito con un codice benchmark che puoi modificare / testare sulla tua macchina: github.com/stonean/slim#testing
Gerry

5
+1 Slim supporta lo streaming HTTP, stiamo riscontrando problemi con il nostro gateway di pagamento e Heroku, sembra che lo streaming HTTP sia un modo per risolvere questo problema ma poiché la nostra applicazione funziona con HAML questa soluzione non è più un'opzione
Flov

1
@DamianNowak Penso che la tua affermazione sia eccessivamente generalizzata. Probabilmente intendi che la velocità non dovrebbe essere necessariamente un fattore decisivo, dati altri fattori. Inoltre, cosa succederebbe se una biblioteca fosse abbastanza lenta da diventare un collo di bottiglia? Sono sicuro che gli sviluppatori se ne accorgerebbero allora. Gli sviluppatori devono dare un po 'di peso alla velocità, o non sarebbero molto intelligenti, eh?
Kelvin

16
L'ottimizzazione prematura non è una buona idea se richiede molto lavoro aggiuntivo, ma la semplice scelta di una libreria simile rispetto a un'altra a causa di un significativo vantaggio in termini di prestazioni non è prematura.
Jamon Holmgren

35

Dalla parte superiore della mia testa questo è ciò che ho pensato

ERB :

Professionisti

  • predefinito fuori dagli schemi
  • non dipendente dallo spazio bianco
  • barriera di accesso più bassa (se proveniente da HTML) poiché il suo HTML con codice Ruby è stato cosparso
  • la maggior parte dei lexer dell'IDE lo legge di default
  • DHH lo preferisce
  • le app legacy probabilmente lo stanno ancora utilizzando

Contro

  • più prolisso
  • i tag content_for negli helper e nelle visualizzazioni possono sfuggire di mano rapidamente
  • content_for tags rende più difficile annidare i tag poiché erb restituisce solo l'ultima riga nel blocco. quindi devi aggiungere una stringa e poi restituirla.

HAML

Professionisti

  • più conciso. nessun tag di chiusura, si adatta a schermi più piccoli
  • struttura visivamente più pulita
  • ha helper incorporati (haml_concat, haml_capture) per utilizzare haml nei metodi di supporto
  • concatenamento di classi
  • un sacco di zucchero sintattico utile come # per div o. per il concatenamento di classi o: javascript per i tag JS

Contro

  • Dipendente dallo spazio bianco, che a volte fa sì che alcuni errori difficili da capire
  • i tag complessi di solito devono ricorrere al formato "hash". (Anche se in realtà penso che questo sia un ottimo esempio di flessibilità per qualcuno che inizia, potrebbe essere un dolore.)
  • aggiunto come una gemma (di nuovo probabilmente un tratto per metterlo come una truffa)
  • i progettisti potrebbero avere qualche problema ad adeguarsi
  • oltre all'avvertenza generale sugli spazi bianchi ... semplici errori di spazi bianchi es. tab e spazi per il rientro, possono causare errori nelle pagine di produzione che le normali specifiche / test non rileveranno. Morale: aspettati una maggiore necessità di test di visualizzazione e possibilmente non utilizzare haml per visualizzazioni mission critical, a meno che tu non sia sicuro che i tuoi test stiano testando il rendering effettivo della vista.
  • è più lento (di erb)
    • avvertimento: questo è il codice ruby ​​di cui stiamo parlando se la velocità è un problema di blocco nella tua applicazione ci sono alternative a ruby, ad esempio haskell

Aggiungerei che Haml è più lento in termini di prestazioni rispetto a erb come truffatore.
bkunzi01

Sì. di sicuro. L'ho aggiunto
ingegnere

1
Se ti piace HAML e sei preoccupato per le prestazioni, prova Hamlit. Ho visto un grande miglioramento nella velocità di rendering delle mie app quasi alla stessa velocità di ERB. github.com/k0kubun/hamlit
Jorge Najera T

21

La domanda per me si riduce a: preferiresti mettere %prima di ogni tag o |prima di ogni nuovo blocco di testo?

Sottile:

 tag(attr= "value")
  | text

Haml:

 %tag{attr: "value"}
   text

Un'altra cosa a cui prestare attenzione: haml assume uno spazio bianco tra le nuove linee ( rimuovi gli spazi bianchi in haml ) mentre slim non assume nessuno spazio (aggiungi spazi bianchi in Slim qui e qui )


9
+1. Ma la pipe non è necessaria per il testo sulla stessa riga del tag. È necessario solo se la prima riga di testo all'interno di un tag non è sulla stessa riga del tag. Ogni riga dopo la prima non ha bisogno del tubo, a causa del rientro.
Kelvin

In realtà mi piace questo aspetto dello slim, poiché mi rende molto difficile scrivere stringhe non internazionalizzate.
KonstantinK

sicuramente |per ogni blocco di testo sopra %per ogni tag. Ci sono molti più tag che blocchi di testo letterale. Una piccola, ma semantica vittoria per me con slim è che qualsiasi html letterale grezzo con <>tag utilizzati è preceduto da un esplicito |. Preferisco "tutto è sottile a meno che tu non lo renda esplicitamente letterale con |" oltre "tutto è letterale finché non lo fai haml con a %.
ahnbizcad

Penso che Slim assomigli più a HTML ( attr="value"), mentre Haml assomiglia di più a Ruby ( {key: "value"}come Hash).
Franklin Yu

16

https://github.com/scalp42/hamlerbslim - è un benchmark indipendente che mostra Slim ed Erb come vincitori, dal punto di vista delle prestazioni (slim tende a ridurre anche le dimensioni dell'output HTML.)

La mia opinione personale è che nel complesso Slim e Haml ti faranno risparmiare tempo (== denaro) in termini di manutenzione, a condizione che tu abbia persone esperte di Haml / Slim che si prendono cura delle tue opinioni.

Se non hai quelle persone, Erb è sicuramente la strada da percorrere, perché nonostante la migliore volontà al mondo, ci sono molte persone molto economiche disponibili che possono lavorare con HTML / Erb, ma trovano Haml / Slim un completo mistero.

Meglio di tutti i casi, addestrare queste persone a usare Slim o almeno esporli ad esso e mantenere il numero di coloro che "lo capiscono".

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.