[nzoschke]

Cute name and well executed project.

But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste.

I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.

[Sapient]

Just reading your comment, it occurred to me that this is an editor problem.

What we actually need are editors in which you can set you language (haml, slim, less etc), and then those are compiled and saved, in realtime to html, erb, css etc.

Not having used too much Coffee Script yet, I don't know what the transformation from CS -> JS -> CS would result in, but I believe HAML -> HTML -> HAML would be pretty much 1:1, and html2haml already produces pretty much exactly the same haml I would have produced if I had done the conversion manually.

[Cushman]

One of the goals of CoffeeScript is to produce only well-formed, compliant JS. JS to CS conversion would go against that.

[bergie]

There is http://ricostacruz.com/js2coffee/

[Cushman]

Yeah, good catch— I didn't mean to say any JS->CS conversion was bad, just that it shouldn't be a part of the core language or of a real workflow.

[iloveponies]

I can see such a conversion like that leading to a scenario where someone writes some broken markup and the conversion to and from formats only makes the situation worse.

[Sapient]

You are of course correct, this was a horrible idea!

[Sapient]

I don't know if this reply was read as being sarcasm, but It honestly wasn't. I was wrong about the whole idea, it would never work.

[danenania]

Eh, it's an interesting line of thinking.

[joeyespo]

While I also think this is too indirect for my taste, I'd really like to know why the maintainers hate it. Is it simply because they've never learned HAML and how to debug/maintain it? Or because it truly is a nightmare?

I'm interested because I was thinking about trying it. I've been wondering about the maintenance implications though.

[jarin]

Most of the "I hate Haml" arguments can easily be solved by use of filters (e.g. :markdown, :textile, :javascript, :plain, :erb, etc) and/or proper use of helpers or cells (I prefer cells).

The things I most often see people doing wrong are trying to format body text with Haml and putting excessive logic in your Haml templates (which is something to look out for anyway, even if you use erb, slim, or whatever).

[nzoschke]

The former. The first guy that loves Haml a lot has used it on tons of projects, and knows its quirks, has his own clever tricks, etc.

Someone else comes along and has to set up a Ruby environment and learn a new syntax (for layout and templating) just to add a new element to the page. That gets frustrating really quickly.

Haml and its like are not a nightmare at all. I do appreciate the elegance of the resulting code and this offers a lot of benefits. It's just hard to get everyone to buy into it on a team.

[danenania]

I don't really get this. Conceptually, haml IS html. Sure the syntax is a bit different, but it's hard for me to imagine that a decent programmer would get hung up on this. Same with coffeescript really. If a cleaner syntax on top of a language scares you, you don't really grok the original language all that well in my opinion. There are certainly arguments for sticking with vanilla html/js, like the potential minor hassles of dealing with file conversions and debugging generated code, etc., but fear of a new syntax that can be learned in 15 minutes is a weak one.

Edit: I do grant that js to coffeescript is a bit more of a leap than html to haml since coffeescript actually introduces some new language concepts.