eRuby means embedded ruby; embedded in xhtml, that is. The result is often a file with the .rhtml extension, though this is somewhat arbitrary like all dot extensions on web pages, because it depends on your server setup. The user-agent (browser) usually doesn’t care.
eRuby is pretty cool but not as well documented as embedded PHP or Perl or Python. It comes in a few different implementations: ERb, eruby.cgi and Erubis. Erubis is supposedly the fastest in a landspeed test, but least used. Erb is of course the widely used standard in Rails. eruby.cgi is the best bet of the 3 though for speed and practicality on a shared-hosting service. As far as I know, when creating a web page with embedded ruby, it is identical with any of the 3 eRuby implementations. The difference is the server setup.
Well, ok. So what!? Right? It amounts to another templating engine. Right?
Right. But the learning curve is nil, well after learning Ruby, it is nil. (pun) Not that any other templating systems (Smarty for PHP) are that complicated or that different. With Ruby though, you can squeeze in some really concise code. Unlike the lengthy PHP stuff.
If you’re tired of ERb in Rails (I can’t imagine why or how you would be because it is the most painless part of Rails), there is HAML. It is just another markup/markdown substitution for xhtml. It’s not worth the trouble of hacking Rails or learning HAML. HAML is just a curiosity. It looks to be shorter or something, initially, but to use it properly, you still have to know and mentally write xhtml. So, why introduce another layer of code that isn’t abstraction, just substitution. You see, HAML looks smaller until you recall that xhtml elements often have attributes that you need to use! This is when you find out how the HAML isn’t really low-fat after all. It simply adds obfuscation to what was ledgible and increases the chances of making mistakes and not finding them. (if not for you, then for the next person who has to maintain the site you made into a pig-sty).
I want more. I want to have a CSS Pre-processor too! I want to be able to use variables in my style sheets. Then all you need to do is load an itty-bitty associative array (also called a hash) to change a color scheme, etc…
Perhaps variables will make it into CSS 3, but by the time it is both official (er, “recommended“) and supported by browsers everywhere, I will be too old to care. (Tim Berners-Lee is a genius, but he’s not a fast-paced pushy one.)
Also, you may want to embed your CSS in the web page. You can. Blogger does it. If you’re building dynamic, server-parsed, templated pages anyway, why not? (I’m seriously starting to ask myself this question.) Well, because of accessibility issues, I suppose. I like accessibility issues, partly because they give me a good moral reason not to fuss or fidget with hard to code pages that break everywhere!
Alas, I have yet to find a CSS preprocessor as I want. Oh, the HAML bunch mentions a CSS preprocessor on the Wikipedia HAML page and they call it SASS! But, this SASS really is low-fat so lean it’s vaporware that doesn’t exist.
2 comments ↓
Umm… Sass has been released for a while.
And no, its not dynamic in the way that you render it on a page-view and pass in dynamic variables. You set them in the header of the Sass file. The CSS is created only once in production mode, and every time in development.
The idea is that when you are working on a seriously large project, its good to be able to change colors sitewide easier than with a find-and-replace. Also, you can do some calculations with it about the sizing of the elements on your page. Think that bar should be bigger? If its a properly built sass file, you only change something in the header.
Here is someone’s post about their experience with Sass: http://blog.sourcecraft.net/2007/04/02/sexy-css-with-sass/
Anyhow, thanks for the feedback. Haml is less for people like you, and more for integration teams with designers who find XHTML and Rhtml difficult to work with and understand. Also, if you have elements with lots of attributes, then you can easily use our Helper/Builder syntax that is built in.
def my_crazy_page_element_with_lots_of_shit
open :div, :class => “magic”, :somecrazy_variable => :boo,
:other_stuff => super_magic, :blah => blah do
open :whatever, tag_innerts()
puts “Some string straight to buffer”
end
end
It may seem like a crazy-weird or even stupid idea to many. And maybe, for them it is. But, I’ve quiet enjoyed using Haml. And so have others. I assume you can respect that others enjoy it, even if you are happy enough with your status-quo.
-hampton.
Ah, hampton, I hope you weren’t too peeved by that post. At the time I wrote it, it seemed that indeed Sass was nowhere to be found. I couldn’t (at the time) find any working links to it. For me, yeah the status-quo is fine. I’m into less is more in terms of design (your own haml pages are a good example of that).
Your own site has better examples of your stuff in use though. That link pretty much showed me what I think, only slightly less typing. But with a good editor, like TextMate, css and xhtml and stuff is all a cake walk. The best use I’ve found for any markdown is simply sanitizing input from untrusted sources, while allowing those sources to contribute. (e.g. wiki-style things)
I’m pretty shocked that any designer wouldn’t learn xhtml and css. If they can learn the arbitrary rules of print typography, that stuff is nothing. Then again, maybe it’s not so shocking, in art school, when I took design classes, they were always amazed that I could actually draw! I was amazed that they couldn’t!
Maybe at some point I’ll have time to give Sass a second look. No disrespect intended. Indeed, keep up the good work.
Leave a Comment