On Monday I was meant to be learning how to use the Grails framework (following up the impressive Grails site that Sky has launched) but I instead got distracted into scratching another itch, using Sinatra with JRuby. Since I was doing a little REST application I thought I would also give Haml a go as it promised a far easier way of generating HTML responses.
Installing both Gems was easy as ever and Sinatra was really easy to understand conceptually. Put the HTTP method name, the URI pattern you want to match and then the return value of the block is what goes back to the client in the response.
So for example to map “/hello” to the plain text response “Hello World” you simply have.
get "/hello" do "Hello World" end
Fire up the script (with necessary requires) and a HTTP server is set up and running. It really couldn’t be simpler. You can use a :symbol in the URI matcher and then access it through the params hash. Within half an hour I was starting to add resources into my served HTML and I felt like master of the REST UNIVERSE.
Sinatra is a really smart piece of code that makes it simple to write a basic web application. I have loads of ideas of how it could be useful but one of my first thoughts was that it actually does a good job of solving the issue of GUI platforms.
My next project is to see how it works with posting data back to the app but on the face of it it all seems straight-forward.
Haml is another story. It is undoubtedly a good idea and on the right track. A DSL for creating HTML the method html for example creates a block html tag while p “Hello World” creates a paragraph tag with the parameter as the content. Hash parameters sent to the method become attributes of the class.
It is much quicker than generating the HTML by hand but often not by much. That is because Haml has not found the same easy metaphor for code and content that Sinatra has. It is very picky, constantly harping about two-space indentation (no more, no less, don’t dare use tabs you bastardo!) for example, it sometimes throws a stack trace that failed to make it to Sinatra leading to a blank screen on the browser and hunt into the console for a clue as to what has gone wrong.
The documentation is to poor to figure out why the library doesn’t accept what you are doing and I am still baffled as to whether the module handles inline tags or whether you are meant to devolve all of that to Textile. Passing parameters to Haml templates seems unnecessarily complex (the only way I could get it to work is with normal string interpolation, it’s a solution but it seems to break the DSL concept) and mixing inline formatting with parameters baffles me still.
Haml makes more sense to me than RHTML style templating but its claim to simplicity and enjoyment seems to come only with a deep understanding and long experience with using it. It took me 20 minutes to fall in love with Sinatra but it took 20 minutes for me to get a working Haml page. And I didn’t enjoy myself doing it.
3 thoughts on “Sinatra and Haml”
I’ll have to check out Sinatra. Sounds interesting.
I do think, though, that you might want to give Haml another shot. There have been some recent updates, and the documentation in its current state addresses all the questions you asked. And once you get the hang of it, it’s so much faster than HTML.
I will certainly be willing to give Haml another go. I also have an idea for a project so maybe I’ll be posting about 2.0 soon.
Just started to play with Sinatra myself, but have been a long time haml fan. Stumbled across your site from google while trying to see how difficult it would be to combine the two.
I realize that this is a bit old now, but I wanted to call attention to my favorite bit about haml, which is actually using it in conjunction with sass for the css. I find that the mapping between dom elements & class names becomes easier to picture conceptually, and therefore leads to much cleaner and easy to maintain stylesheets. It is one extra thing to learn, but for me it was more than worth the effort.