Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Lessons:2Length:10 minutes
  • Overview
  • Transcript

1.2 Choose a Ruby Template Engine: ERB vs. Haml

In this lesson, I’ll show you how to implement the same example in both the ERB and Haml templating engines. I’ll explain the syntax of each engine, and I’ll compare the strengths and weaknesses of each one. Then, I’ll show you how to compile from Haml back into ERB.

Related Links

Code Snippet

This snippet of Ruby code uses the haml2erb API to convert a Haml template file into ERB.

require "httparty"

haml = File.read("demo.haml")
response = HTTParty.post "https://haml2erb.org/api/convert", {
  body: {
    converter: "herbalizer",
    haml: haml

puts JSON.parse(response.body)["erb"]

1.Choose a Ruby Template Engine: ERB vs. Haml
2 lessons, 10:14

Free Lesson

Choose a Ruby Template Engine: ERB vs. Haml

1.2 Choose a Ruby Template Engine: ERB vs. Haml

In this very short course, I'll demonstrate the differences between using ERb and HAML in a standard web application in Ruby. Consider the following example where I have a diff with the idea of header. Inside I have a form that points to a search route somewhere with the ID of search form. We'll have a field set with a paragraph and this paragraph will have a text field tacked that's common in Braille apps. It will have the name search and a placeholder text something like searched him here. This will appear as a grade out text in the input. We also have an unordered list in line 23. We'll loop through each of the posts, for example, from a block. Each post will be an argument in this block and so, for each post, we'll have a list item with the ID of post dash. And then, we'll interpolate the ID of that post into the attribute. Will have a header with the posts style, then the post spotty, and finally a list of tags. The list of tags will have a class and then for each item, so for each tag we'll use post.tags on each for example. And then the list item will match that specific tag. That's it, nothing too fancy. Then we're just gonna close every single element in the HTML. This is standard and required to close every single tag, so this amounts to around 25 lines of code. If you strip the blank lines, it will be something like 23. Now, watch as I go to the HAML example. Let's close this one and open the HAML example. As you can see, the example is much smaller. We have a pound header here that demonstrates that we're typing a div. So this would be exactly the same as typing percentage div and then pound header. But the convention in HAML is to omit div tags. They are automatically converted to div tags, so you can just omit them. For the remaining list of elements you type in percentage and the name of the element. For example, the form, the field set, the paragraph and also the unordered list, the headers, the list items, all of that. The way you define attributes is with the pair of brackets. Each different attribute would have a key value pair the same as you would in a regular Ruby hash. The keys are symbols and the values can be either integers or strings or floats. In order to interpolate Ruby code, you use the equal sign to render something into that element. In this specific scenario I'm using the equal sign inside a paragraph. So the text field tag will be generated inside the paragraph. If you just want to use some code then you stick to the dash. The dash will not print anything into the screen. So the equal sign will effectively render something to the screen while the dash sign will not. So we're gonna look through each of the posts and we're not going to print out the return value. Rather for each post in the block we'll render the list item as usual using percentage ally. And then, as I've the attributes are key value pairs. And because this can be interpolated with Ruby code, you just use direct string interpolation # and then the curly braces allow us to inject Ruby code into there. Next we're gonna use the header which will print out the post item. Then the post's body and finally we'll use the unordered list element with a class of tags. This is how you define the list and then we'll list through all of the post's tags and create a list item with that specific tag. So what is the difference, really, between one and the other? Well first of all, I like HAML better because I don't have to type that much. You see the other example was like 25 lines of code including the two blank spaces as we have here. This one is around 13, if you exclude the blank lines the end result is 11 lines, so that's less than half of the code then you would type. Of course that you could go here to the example and just omit all of these lines and mix these all together. Just print out a single line with all of these instructions, right. This would result in less code but that's not exactly the point. We want to be professionals and we want to make sure that the code is readable. So these lines must be considered in order to be readable but personally, I find this to be a lot better. It's simpler. It doesn't have as much clutter as the ERb example. Also because it is white space sensitive you are basically enforced to do things right. Most people out there complain about this feature, about HAML. The fact that it's white space sensitive means that you have to do a strict representation of what you need to accomplish with the markup. I personally find this a feature and not really a nuisance. It enforces a structure and this conveys a lot less effort for my brain and I'm sure that it will be for you too. You don't have to think about how to structure your HTML because Haml already enforces it for you. So, the natural cadence of the markup allows for better search ability. One final thing that I like about HAML is the fact that the declaration of IDs and classes resemble really closely the way you declare CSS rules for example. This is the same as you would declare in CSS an element with the ID of Hatter. And that's pretty cool, the same way for the classes, dot, and then the name of the class is the way you do that in CSS. I think it's a really short and efficient way to declare classes and IDs which are most likely the most common attributes to declare in an html sample. These are the main differences between Haml and the ERB. I personally prefer HAML but you might be more into ERb you like HTML and you don't want to run away from it that's totally fine I understand if you want to stick to the basics. If you want to switch from HAML to ERb, at least in the courses that I produce, there's a nifty little tool that I want to show. Let's go to the browser really quick. Let's type in haml2erb.org. This website has two boxes. You paste in the HAML in there, at least for the courses that I produce, just paste that in, and you will get an output. Let's see, let's go to this Haml. Let's copy it, so there you go. Let's paste that in and you'll see that automatically you get a nice representation of html with ERb code in there. So that's pretty cool, if you want to you can even add the API. There's an API reference here that you can use for example just type in a curl command to this URL. Ensure that is a POST request and sent in the haml to be converted, the end result will be a JSON body with a success keyword and an erb key which will have the end result. Most likely, you will stick to this converter but if you're more tech savvy then go ahead and use the API. It's very easy to accomplish that. It just turns out that it's really easy to use the API with a really simple Ruby script. Let's require the HTTParty gem, which allows us to send a post request like this. First of all, we're gonna read the HAML content from File.read, and we'll pass in the path to the file which is just run right here at the bottom. Next we're gonna use the post method from HTTParty we'll pass in the URL for the API and then we'll pass in a hash with a body. The body will match the parameters that we need to send according to the specification we just saw. We used the herbalism converter And we'll pass in the HAML in the HAML key. At the end, we'll get a response and if it turns out to be a successful one, we'll just parse the entire response with JSON.parse. We'll fetch the response's body and will just retrieve the ERb content. This is as easy as typing Ruby and then demo.rb which is the name of the file. If I do that you will see the correct ERb response being retrieved. There you go. If you wanna check the source code for this it is in the description below. If you have any questions around this course then feel free to go to are Envato forums. Post your questions there, and everyone will be able to help out. Also, if you feel like you have a quick question that should be answered pretty fast, go to our Twitter. Either @Tuts+ or myself, @josemota.net. My name is Jose Mota, and I hope to see you very soon.

Back to the top