I kind of wish they would go further. While I prefer Rspec, I understand and sympathize with those who feel Test::Unit is a better default.
But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger.
I agree with Katz here. If anything, Rails has shown remarkable restraint in the face of a smorgasbord of shiny, new, and often superior, competing technologies.
I agree that it's much nicer than ERB for HTML, but I still use ERB for, e.g., config file generation.
HAML, though, shares the same fundamental problem with ERB: it's straddling the code/template fence. I wrote the Hoshi ( http://github.com/pete/hoshi ) gem to address this, and used it in the last Rails application I wrote (still in production), and still use it for HTML when I need that. (It's still in the "personal itch" phase, so it's only maintained when I notice that W3C doesn't like something or when I'm missing a feature. For example, I haven't done any HTML5, so I haven't put any in.)
For anything requiring a wall of text (in HAML, ERB, Hoshi, whatever), I think it's a mistake to put it into your view code. Make a place where copy goes, decide on a markdown format, and write a helper that pulls in and processes that text. Even if the coders are writing the copy, it's helpful to have the text seperate, and easier to edit besides. And if it turns out that you need the text editable via a web UI or something, it makes the change easier: modify the helper to fetch text by name from the database rather than the filesystem, and import all of the text into the database. Everything is easier all around; I'm at the point where it looks like a code smell when I see walls of text (or frequently edited text) in a template.
To me, the pain-point with HAML has always been that it's much harder to teach our front end designers to use it instead of HTML, whereas Sass presented much less of a barrier for them vs Javascript.
HAML feels great for me as a dev vs the verbosity of hand-hacking HTML, but for the guys who spend 90% of their time in photoshop and 10% chopping their PSDs into static HTML to hand to me, I'm not convinced it's worth the lost productivity to teach them a new markup.
I'd really have to question the skills of any person who can't adapt from HTML to HAML. If you can do erb, you ought to be able to do HAML within, at most, an hour of pushing stuff through HTML2HAML.
Speaking of which, HTML2HAML works nearly every time.
I'd say the point is, there's no reason in having them spend any time at all adapting to it just to get right back to where we are, right now -- they churn out readable and workable markup.
We're not having any problems with HTML that HAML would solve.
Haml is great for many cases, but it's terrible when the ratio of text to embedded code gets large. Chris Eppstein, one of the developers of Haml, made a blog post to this effect last year:
It wouldn't ever replace ERB anyway. HAML makes most things easier and terser at the cost of making a few things difficult or impossible. You still need to fall back to ERB occasionally, and it's also used outside of the views. All this makes for a bad default, especially for new users.
(I say this as someone who loves HAML and uses it almost exclusively).
1) You can use ERB in Rails apps without including it in your Gemfile
2) Rails generators spit out ERB. The Haml gem doesn't include any generators, to my knowledge
3) The documentation is ERB-focused
Can Linus single-handedly block changes from getting into Linux? That just seems crazy to me if he can. I get that DHH and Linus have pulpits, but that's all they should have.
It's just extremely disappointing to hear someone say something can't get in, not because of quality, but because there's one person who doesn't like it. With that said, people do fork Linux, see Android. Do people fork RoR and actually produce versions that are used by a non-trivial set of users?
How exactly do you think an open source software project should be managed? People are going to have disagreements about changes, and there needs to be some method of adjudicating those disagreements. Democracy is near-impossible in those circumstances because key problems like suffrage (who counts as enough of a contributor to have a vote?) are hard to fix, and because actual technical expertise is important to decision-making. Wikipedia is probably the best example of a project that's run democratically, by consensus at least, and the net result is that more effort is wasted on politicking than actually writing content. The only reason this even works for Wikipedia is because there's no shortage of people who can write and copyedit encyclopedia articles. Programmers are more scarce, and more allergic to politics.
So benevolent dictatorship it is, plus the freedom to fork. As for Rails, changes like using jQuery instead of Prototype (pre-3.1), or using HAML or something like that doesn't actually require making any code changes. In fact, these controversies are classic bikeshed arguments. It's not a serious criticism of Rails that the default gemfile doesn't include a gem you prefer, because you can change the gemfile yourself. It would be a serious criticism of Rails--and, indeed, a reason to fork--if, for instance, there was strong disagreement with how Arel is implemented. But there's 100x more Rails developers with an opinion over HAML vs ERB than there are Rails developers with the slightest clue about how to implement Arel.
How exactly do you think an open source software project should be managed? People are going to have disagreements about changes, and there needs to be some method of adjudicating those disagreements. Democracy is near-impossible in those circumstances because key problems like suffrage (who counts as enough of a contributor to have a vote?) are hard to fix, and because actual technical expertise is important to decision-making.
Of course there will be disagreements, but no single person should have so much power as to block changes.
I have no particular care about HAML. But rather the notion that any piece of technology isn't in popular OSS like RoR because one person objects. I find that offensive.
Wikipedia is probably the best example of a project that's run democratically, by consensus at least, and the net result is that more effort is wasted on politicking than actually writing content.
The net result is that its useful, LOTS of content generated, and democratic. Arguing is part of a democracy. I don't mind it.
So benevolent dictatorship it is
For all the talk of freedom, this is disappointing.
| For all the talk of freedom, this is disappointing.
You're incredibly naive then. Freedom comes from the license. You can fork and modify to your heart's content. This is how open source freedom works. If you think you can do it better, then do it better in your project. Rails is not some sort of public good that belongs to the people. It is a project that people work very hard on and then give away. And for anyone to suggest that they should not get to decide how things work on the thing that they give away free of charge and for modification is both ludicrous and makes you sound very ungrateful.
Successful projects are successful because the leaders do a good job. They're good at listening, good at saying no, good at rallying support, and good at working with their users and their team. Your vote is with your shoes.
First. Using HAML in your project involves all of adding the line "gem 'haml'" to your gemfile. It's not a big deal.
Second. You just glanced over the possibility that DHH doesn't like HAML for a rational reason, like for instance maybe he doesn't think HAML is that big an improvement over HTML and therefore not worth being a default setting. It's not an irrational dislike that has nothing to do with the qualities of the library itself.
I think you underestimate DHH as well as the rest of the Rails core group.
And yes, Linus can single handedly stop anything from getting into Linux. This is how most open source projects are run, there is a leader at the top and as long as he/she is doing a good job, people follow.
But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger.
I agree with Katz here. If anything, Rails has shown remarkable restraint in the face of a smorgasbord of shiny, new, and often superior, competing technologies.