Jakiś czas temu wewnątrz netguru rozgorzała krótka żarliwa dyskusja na temat “Czy warto uzywać HAML’a”. Małe wewnętrzne lobby, utworzone na potrzebę zdarzenia szybko przeforsowało taką decyzje i teraz programiści szczęśliwi mogą go używać do woli. OK.
Tylko po co to zamieszanie??
Gdy rozwiniemy skrót HAML (w moim przypadku zezując na drugi monitor gdzie otwarta jest strona projektu) dowiem się żę jest to (x)HTML Abstraction Markup Language – póki co nic fajnego. Starając jakoś to przybliżyc musimy powiedziec że jest to język używany do tworzenia szablonów, mogący zastąpić popularnego rhtml’a w frameworku RoR.
Pomijając moją nieudolną próbę definicji tego pojęcia HAML to w praktyce poprostu jeden wielki skrót HTML’a. Z założenia autorzy napisali go by ulżyc programistom framework’a RoR, ale plotka głosi istnieją wersje, które spokojnie zadziałają również w php i ASP .NET.
Jego podstawową zaletą jest fakt, że jest go najzwyczajniej w świecie mniej. To co tradycyjnie w rhtml’u wymagało napisania czegoś takiego:
<div class="jakas_klasa">
Treść która nas urzeka
</div>
w HAMLu sprowadza się do:
.jakas_klasa Treść która nas urzeka
I uwierzcie mi że potem jest tylko lepiej. Przeciętnie takie pisanie szablonu w HAML’u to ok 40% kodu, nie mówiąc już o tym jak przejrzyście robi się się w takich szablonach. Dla porównania przykład, który możemy znaleźć w tutorialu do HAML’a.
Rhtml:
<div id='content'>
<div class='left column'>
<h2>Welcome to our site!</h2>
<p>
<%= print_information %>
</p>
</div>
<div class="right column">
<%= render :partial => "sidebar" %>
</div>
</div>
HAML:
#content
.left.column
%h2 Welcome to our site!
%p= print_information
.right.column= render :partial => "sidebar"
Widać tu od razu kilka sztuczek jakich używa się w HAML’u by definiować znaczniki. Tworząc nowy znacznik używamy składni %nazwa_znacznika, lub %nazwa_znacznika.klasa gdy chcemy stworzyć znacznik z atrybutem class albo %nazwa_znacznika#jakis_id gdy potrzebny nam atrybut id. Warto zauważyć dwa fakty – po pierwsze, html’owy div jest znacznikiem domyślnym w HAML’u i nie musimy go pisać, starczy zdefiniować tylko class lub id, po drugie HAML jest “white space sensitive” jak piszą autorzy – zmusza nas on do poprawnego wcinania kodu co w praktyce okazje się mieć zbawienne skutki. Wszystkich zainteresowanych większą ilością informacji zachęcam do dokładnego zapoznania się z tutorialem.
Część z Was pewnie jest w tym momencie wciąz zdegustowana początkiem mojej wypowiedzi gdzie wspomniałem, że “programiści szczęśliwi mogą go używać do woli”. Teoretycznie ze względu na fakt, że HAML oferuje nam zupełnie nową składnie do tworzenia szablonu, moglibyśmy powiedzieć że jest on nieużyteczny dla koderów HTML’a i CSS’a którz wcale nie muszą umieć programować. Ponieważ jest to faktycznie kluczowa kwestia postanowiłem zapytać o zdanie naszego firmowego kodera. Zapytany o HAML’a Marcin powiedział:
HAML jest tak genialny, że po tym jak się go nauczyłem nie mogę zasnąć wieczorem zmartwiony myślą, iż nie jest mi dane używać go w każdym projekcie
(oczywiście wszycy którzy znają naszego kodera wiedzą jak bardzo sparafrazowana i ocenzurowana jest ta wypowiedź)
W praktyce faktycznie okazuje się, że autorzy nie kłamią pisząc:
Haml feels odd for the first 20 minutes, but then after that YOU WILL BE FASTER.
Oprócz genialnej w użyciu składni, najnowsza wersja 2.0 HAML’a oferuje nam nawet większą prędkość renderowana szablonów nić tradycyjny Rhtml, co wytąca jeden z najpoważniejszych argumentów jaki mieli sceptycy. Co więcej faktycznie po pierwszych 20 minutach prób z HAML’em jesteśmy już w stanie spokojnie z niego korzystać co skutkuje jak określa jeden z naszych teraz już “szczęśliwych” programistów:
Jest mniej tego plugawego htmla w kodzie!
(tym razem bez cenzury :P )
