Alternativer til Erb igjen

En av de aller første tingene jeg skrev om på cjohansen.no var et alternativ til Erb ("embedded ruby"), DRYML (fra Hobo). I dette innlegget touchet jeg også innom #haml, som jeg nå har oppdaget på nytt.

Ved en tilfeldighet dumpa jeg borti #haml på nytt for en liten stund siden. #haml er et templating-system hvor den resulterende HTML-en faktisk blir tatt på alvor. Jeg merker meg at jeg fnøs av syntaksen i mitt snart to år gamle innlegg, men jeg kan ikke på det tidspunktet ha skjønt hvordan #haml fungerer.

Et eksempel

Fritt klippa fra #haml.tutorial:

Erb:

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

Look at that. Doesn’t that just make you smile? Every character means something.

Ja, her må jeg jaggu fleske meg si meg enig, dette får meg til å smile. Hva er det egentlig som foregår her?

Indentering er påkrevd. Akkurat som Python bruker #haml indentering til markering av blokker. Me likes - det er både nyttig og oppmuntrer til god kodestandard
Tagnavn angis med %tagnavn, id med #id og klasser med .klasse. Disse kan kombineres.
Implisitt element er div - #content blir til <div id="content">...</div>
Vilkårlige attributter (inkludert id og class) kan kodes med en hash: %abbr{ :title => "HyperText Markup Language" }= HTML
Alt etter likhetstegnet parses som Ruby
Fordi indenteringen angir blokker trenger man ikke avslutte noen elementer

Jeg må si at jeg er ekstremt positiv til denne måten å gjøre templating på. Bare se hvor mye mer kompakt #haml-eksempelet er. Som de sier: "Every character means something" - sånt blir det både større oversikt/forståelse og færre bugs av. Men hvordan blir det med ytelsen?

I tillegg til at #haml gir et ryddig inntrykk i templates så vil den som default også indentere all output-HTML. Det vil si at dersom du hele tiden bruker #haml vil du få perfekt indentert HTML på klienten - noe som tidvis kan være svært nyttig.

Ytelse

Å introdusere overhead i viewet vil - ikke overraskende - påvirke ytelsen din. Når du leser den siste setningen i forrige avsnitt burde dette bli svært tydelig. Det kan derfor være tilrådelig at man konverterer noen store templates og benchmarker forskjellene før man setter igang for fullt. Nå skal det også nevnes at pen output kan skrus av i produksjon for å spare noen millisekunder.

Jeg har søkt og søkt for å finne noen skikkelige målinger, men kommer kun opp med spekulering, utdaterte innlegg og luftige formuleringer på ytelse og #haml. Om noen sitter på oppdaterte tall, del gjerne. Det beste jeg fant var et innlegg fra en av utviklerne som er over et år gammelt. Her vises det til at #haml er røffly 1.15 ganger seinere enn Erb. En anonym og ubekreftet kommentar som er relativt ny informerer om at #haml nå er smått raskere enn Erb(!)

Stemmer sistnevnte er det svært interessant.

Bruksområder

Som template-system er #haml brukandes i alle tilfeller hvor man har Erb i en vanlig Ruby-applikasjon. For Rails sin del er vel egentlig e-poster det eneste stedet jeg ikke ser for meg at #haml vil gjøre så mye nytte ettersom e-poster (mine ihvertfall) stort sett er tekst, ikke markup. Selv har jeg testet det på enkelte templates som ble unødig klønete med Erb, så som en menykomponent.

Prototyping

Ofte jobber jeg med å implementere frontenden til et system, og er da sjelden alene om å implementere frontendkoden i et eller annet system. Jeg bruker ofte Rails til dette. Prototyping på et statisk nivå faller fort sammen, og Rails gir meg fleksibilitet nok til å være effektiv - selv når det kommer store endringer med tilbakevirkende kraft.

Når man progger prototype som andre skal implementere er det greit om HTML-en er leselig, og i et sånt scenario er #haml perfekt! Du trenger ikke å ofre leseligheten på templatene for å få god leselighet på output-HTML. Dette, sammen med enkelheten gjør #haml til et ypperlig prototype-verktøy.

Editor-støtte

Etter litt eksperimentering er det bare en ting som plager meg - editorstøtte. Jeg brukte litt tid - uten å lykkes - på å finne syntax highlighting til Eclipse/RadRails/Aptana. En slik nevnes, lucky-dip haml editor, og den dukker også opp i kildekoden til Aptana, uten at jeg kan se at det fungerer, eller at det finnes noe særlig informasjon om den.

For Emacs fant jeg haml-mode, men med 90% tekst i blått imponerte ikke denne heller. Jeg trenger god syntaks highlighting for å orke å stirre på koden, så om noen har noen tips, kom med dem!

Det blir artig å jobbe litt mer med #haml og bli bedre kjent med fordeler og ulemper. Noen andre som har erfaringer med dette systemet?

Tweet this

Publisert 6. november 2008 under ruby, verktøy, rails og html.

Muligens relatert

Er ikke Erb bra nok?