Hi guys, Preface: I've never used Haml. Here are some of my reasons for not using it, aside from not *needing* to:
For a templating system for HTML, I would have a hard time moving to a totally abstracted syntax like Haml. I think Erb-like templaters only intercede where absolutely necessary to build the HTML elements. If you can read HTML, you can understand most .erb files, maybe minus the few Rails (insert-fav-framework-here) view helpers. If you need to move away from Haml at some point down the line, I could imagine it being a real pain to migrate all your views (I'm sure there are migration libraries though). I like keeping the HTML mostly intact so that it is easier for others to support the project if the Haml guru's leave. The same goes for something like CoffeeScript. If you are coding in Javascript, just write it. It's not THAT bad. Libraries like jQuery help easy the keyboard strain. Having a completely abstracted syntax for something else that gets translated and rendered into a different language can cause legacy maintenance issues down the road. Popular libraries change fast, but things like HTML and JS don't as much. Library support gets dropped for a lot of little projects in the Open Source world over time. That being said, I would welcome the chance to use CoffeeScript or Haml at some point. My mind is open to them, but I'm wary. - Adam On Wed, Jun 8, 2011 at 1:39 PM, Rob Kaufman <[email protected]> wrote: > Pardeep, > Instead of just saying "HAML is cool, use that", I'll join Matt and Jay > in trying to answer your questions: > > Did you manage to get past your HAML hurtles with Jay's advise? It is > worth trying out and does work out of the box for most of us. > > Erubius is essentially a just a faster ERB parser. In practice you only > really see a benefit if you are parsing fairly large templates or really > need that 2% performance bump on regular requests. > > I'd only recommend Tenjin if you had folks on your team that already use > it. They go on and on about how fast it it... but speeding up something > that takes less that 5% of your request cycle isn't really that important. > And having something that is less main stream in the Rails community just > for that last little bump probably isn't worth it. > > Like Matt, I feel like HAML is nice, but comes at the cost of being harder > for non-devs to use. Patrick may be tired of hearing that as a reason, but > that certainly doesn't make it any less valid now than it was 5 years ago. > Sorry dude, I know you are an amazing designer / developer, but that is a > rare bird and the rest of us are frequently dealing with people who say > things like "Wait a minute, I have to go through all of this just to load > the app AND learn a new mark up language? Can't I just edit some HTML files > on and FTP server some where?" It is a serious concern. > > HAML compares pretty closely with Ruby's default ERB implementation in > production at this point as far as performance goes. > > Best, > Rob > > On Wednesday, June 8, 2011 at 12:52 , Patrick Crowley wrote: > > i would prefer to work with a designer who is willing to learn haml, and i > have worked with a few that were... it's not exactly difficult to learn. but > if it's absolutely not an option then erb is the best choice. > > > +1 on this. > > HAML is a lightweight template language for taking the pain out of writing > HTML, and I say that as a designer who can write very good semantic markup > by hand. > > If you can write HTML, you can write HAML. It's just not a big deal... and > I'm super tired of hearing folks use designers as an excuse for not using > HAML. > > That said, if your designer can't write their own HTML, you've got bigger > problems. ;) > > -- Patrick > > > > > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
