erb, haml czy slim: który proponujesz? I dlaczego? [Zamknięte]

103

Uczę się Railsów i widziałem te silniki szablonów. Nie mam z nimi doświadczenia (tylko erb).

Ale ponieważ jestem początkującym, jestem naprawdę zdezorientowany. Który proponujesz i dlaczego? Erb, Haml czy Slim? Podaj powód, dla którego preferujesz jeden z nich. Jeśli masz inne zalecenia, daj nam znać.

EDYCJA: NIE szukam tutaj zwycięzcy. Chcę tylko usłyszeć twoje opinie na ich temat, ich składnię, szybkość wykonywania i tak dalej.

Omid Kamangar
źródło
7
Krótka odpowiedź brzmi: jako początkujący użyj ERB.
Scott Schulthess,
Chociaż nie jest to silnik szablonów, możesz zajrzeć do klejnotu dom, który opracowałem. Pozwala na pozorne pisanie kodów HTML jako Ruby.
sawa
15
To „nie konstruktywne” pytanie było dla mnie niezwykle pomocne. Dzięki za pytanie, nawet jeśli mody z jakiegoś powodu nie wydają się pasować. To był jeden z najpopularniejszych hitów Google, a wiele odpowiedzi pomogło mi w podjęciu decyzji.
Andy Baird
2
nadal jest numerem 1 w Google dla
zapytania

Odpowiedzi:

67

ERB jest dobry głównie, jeśli masz projektanta stron internetowych, który będzie pracował na zwykłym HTML i nie zna ani haml, ani slim. W ten sposób może pisać HTML i możesz osadzić logikę ruby ​​z odpowiednimi tagami.

Jeśli pracujesz zarówno nad logiką HTML, jak i ruby, lub twój projektant jest gotowy nauczyć się czegoś nowego (np. HAML), wybrałbym HAML. Jest o wiele bardziej przyjazny dla rubinów, znacznie zmniejsza liczbę znaków i jest o wiele bardziej czytelny niż ERB.

Na przykład (pobrane z oficjalnej strony HAML ):

W ERB twój widok będzie wyglądał następująco:

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

Będąc w HAML będzie to wyglądać tak:

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

Dużo czystsze!

A jeśli chodzi o różnicę między HAML i SLIM - nigdy tak naprawdę nie pracowałem z SLIM-em, ale myślę, że to kwestia gustu - spójrz na obie składnie i zdecyduj, która wygląda lepiej w twoich oczach. Nie sądzę, aby między tymi dwoma był zdecydowany zwycięzca (HAML / SLIM).

Erez Rabih
źródło
Przeczytaj - ostatnie zdanie o ostatecznym zwycięzcy dotyczyło HAML i SLIM (odpowiednio zredagowane).
Erez Rabih
1
Tak, +1 za to, mimo że Haml & Slim wyciągają wszystkie śmieci z HTML i z braku lepszego wyrażenia, totalnie niesamowite, wiele osób tylko HTML po prostu nie może się tym zająć (lub nie ma 't handcoders w pierwszej kolejności, lub polegaj na skrawkach i kopiowaniu makaronu.)
ocodo
8
@ErezRabih tak naprawdę istnieje duża różnica między HAML a SLIM. Slim jest znacznie szybszy niż HAML. Posiada również składnię czystsze i pozwala pisać bardziej czysto atrybutów HTML: a href="foo".
Mohamad
87

Dwie duże zalety używania slim over haml:

  1. Slim jest obecnie około ośmiokrotnie szybszy niż haml.

  2. Slim obsługuje strumieniowanie HTTP, podczas gdy HAML nie.

  3. Slim ma bardziej naturalną składnię: a href="foo.html"

Bart ten Brinke
źródło
3
Czy masz wiarygodne źródło swojego oświadczenia na temat szybkości Slim vs Haml? Dużo o tym czytam wszędzie, ale poza stroną Slima na GitHubie nie znajduję na ten temat wielu możliwych do udowodnienia informacji.
Joshua Muheim
4
@JoshuaMuheim Slim zawiera kod porównawczy, który możesz zmodyfikować / przetestować na swoim własnym komputerze: github.com/stonean/slim#testing
Gerry
5
+1 Slim obsługuje przesyłanie strumieniowe HTTP, mamy problemy z naszą bramką płatności i Heroku, wydaje się, że przesyłanie strumieniowe HTTP jest sposobem na rozwiązanie tego problemu, ale ponieważ nasza aplikacja działa z HAML, to rozwiązanie już nie wchodzi w grę
Flov
1
@DamianNowak Myślę, że twoje stwierdzenie jest zbyt uogólnione. Prawdopodobnie myślisz, że prędkość niekoniecznie powinna być decydującym czynnikiem, biorąc pod uwagę inne czynniki. A co by było, gdyby biblioteka była na tyle powolna, że ​​stała się wąskim gardłem? Jestem pewien, że deweloperzy by to zauważyli. Twórcy muszą przykładać wagę do szybkości, inaczej nie byliby zbyt sprytni, co?
Kelvin,
16
Przedwczesna optymalizacja nie jest dobrym pomysłem, jeśli wymaga dużo dodatkowej pracy, ale zwykłe wybranie jednej podobnej biblioteki zamiast innej ze względu na znaczną poprawę wydajności nie jest przedwczesne.
Jamon Holmgren,
35

To jest to, co wymyśliłem

ERB :

Plusy

  • domyślnie po wyjęciu z pudełka
  • nie zależy od białych znaków
  • Najniższa bariera wejścia (jeśli pochodzi z HTML) jako HTML z wkroplonym kodem Ruby
  • większość lekserów IDE czyta go domyślnie
  • DHH to woli
  • starsze aplikacje prawdopodobnie nadal go używają

Cons

  • bardziej szczegółowe
  • content_for tagi w helperach i widokach mogą szybko wymknąć się spod kontroli
  • content_for tagi utrudnia zagnieżdżanie tagów, ponieważ erb zwraca tylko ostatnią linię w bloku. więc musisz dołączyć do łańcucha, a następnie go zwrócić.

HAML

Plusy

  • bardziej zwięzłe. bez tagów zamykających, pasuje do mniejszych ekranów
  • wizualnie czystsza struktura
  • ma wbudowane pomocniki (haml_concat, haml_capture), które wykorzystują haml w metodach pomocniczych
  • tworzenie łańcuchów klas
  • wiele przydatnych cukrów składniowych, takich jak # dla elementów div lub. do tworzenia łańcuchów klas lub: javascript dla tagów JS

Cons

  • zależne od białych znaków, co czasami powoduje trudne do zrozumienia błędy
  • złożone znaczniki zwykle muszą uciekać się do formatu „hash”. (Chociaż uważam, że jest to świetny przykład elastyczności dla kogoś, kto zaczyna, może to być uciążliwe).
  • dodany jako klejnot (znowu prawdopodobnie rozciągnięcie, aby umieścić to jako oszustwo)
  • projektanci mogą mieć problemy z dostosowaniem
  • oprócz ogólnego ostrzeżenia o białych znakach ... proste błędy związane z białymi znakami, np. Tabulatory i spacje dla wcięć mogą powodować błędy stron w środowisku produkcyjnym, których normalne specyfikacje / testy nie zostaną wykryte. Morał: spodziewaj się większej potrzeby testów widoku i prawdopodobnie nie używaj haml do widoków o znaczeniu krytycznym, chyba że masz pewność, że testy testują rzeczywisty renderowanie widoku.
  • jest wolniejszy (niż erb)
    • Uwaga: to jest kod Ruby, o którym mówimy Jeśli szybkość jest problemem blokującym w Twojej aplikacji, istnieją alternatywy dla Rubiego, np. haskell
inżynier Dave
źródło
Dodałbym, że Haml jest wolniejszy pod względem wydajności niż erb jako oszust.
bkunzi01
tak. na pewno. Dodałem to
inżynier
1
Jeśli lubisz HAML i martwisz się o wydajność, wypróbuj Hamlit. Zauważyłem dużą poprawę szybkości renderowania w moich aplikacjach, prawie tak szybko, jak w ERB. github.com/k0kubun/hamlit
Jorge Najera T
21

Pytanie dla mnie sprowadza się do tego, czy wolisz umieścić %przed każdym tagiem, czy |przed każdym nowym blokiem tekstu?

Szczupły:

 tag(attr= "value")
  | text

Haml:

 %tag{attr: "value"}
   text

Jeszcze jedna rzecz, na którą należy zwrócić uwagę: haml zakłada spację między nowymi wierszami ( usuń spacje w haml ), podczas gdy slim zakłada brak spacji (dodaj spacje w Slim tutaj i tutaj )

montrealmike
źródło
9
+1. Ale pionowa kreska nie jest potrzebna w przypadku tekstu w tym samym wierszu co znacznik. Jest potrzebny tylko wtedy, gdy pierwsza linia tekstu wewnątrz tagu nie jest w tym samym wierszu co tag. Każda linia po pierwszej nie potrzebuje rury z powodu wcięć.
Kelvin,
Właściwie podoba mi się ten aspekt slim, ponieważ bardzo utrudnia mi pisanie nieza internacjonalizowanych stringów.
KonstantinK
zdecydowanie |dla każdego bloku tekstu %dla każdego tagu. Znaczników jest znacznie więcej niż bloków tekstu dosłownego. Mała, ale semantyczna korzyść dla mnie ze slimem polega na tym, że każdy surowy, dosłowny html z <>zastosowanymi tagami jest poprzedzony wyraźnym |. Wolę „wszystko jest szczupłe, chyba że wyraźnie uczynisz to dosłownie z |„ ponad ”, wszystko jest dosłowne, dopóki nie zrobisz tego za pomocą a %.
ahnbizcad
Myślę, że Slim wygląda bardziej jak HTML ( attr="value"), podczas gdy Haml wygląda bardziej jak Ruby ( {key: "value"}jak Hash).
Franklin Yu
16

https://github.com/scalp42/hamlerbslim - to niezależny test porównawczy, który pokazuje Slim i Erb jako zwycięzców, jeśli chodzi o wydajność (slim ma tendencję do zmniejszania rozmiaru wyjściowego HTML).

Osobiście uważam, że ogólnie Slim i Haml zaoszczędzą Twój czas (== pieniądze) w zakresie konserwacji, pod warunkiem, że masz doświadczonych ludzi Haml / Slim, którzy dbają o Twoje poglądy.

Jeśli nie masz tych ludzi, Erb jest zdecydowanie najlepszym rozwiązaniem, ponieważ pomimo najlepszej woli na świecie jest dostępnych wiele bardzo niedrogich osób, które mogą pracować z HTML / Erb, ale uważają Haml / Slim za kompletny zagadka.

Najlepszy ze wszystkich przypadków, wyszkol tych ludzi, aby używali Slim lub przynajmniej narażaj ich na to, i zachowaj liczbę tych, którzy „to rozumieją”.

ocodo
źródło