When comparing Haml vs Fortitude, the Slant community recommends Haml for most people. In the question“What are the best Ruby templating languages?” Haml is ranked 3rd while Fortitude is ranked 5th. The most important reason people chose Haml is:
There are plenty of learning resources available for those who want to learn Haml. The [documentation](http://haml.info/docs/yardoc/file.REFERENCE.html) is detailed and well organized, and Haml is easy to pick up.
Ranked in these QuestionsQuestion Ranking
Pro Easy to learn
There are plenty of learning resources available for those who want to learn Haml. The documentation is detailed and well organized, and Haml is easy to pick up.
By using indentation rather than closing tags and eliminating curly braces, Haml is fast to code.
<div id ="lower"> <div class="right column"> <div id="currentDate"><%= print_date %></div> </div> </div>
Can be written as:
%div#lower %div.right.column %div#currentDate= print_date
Pro Clean syntax
Haml's syntax is very clean and pleasant to look at. It doesn't use HTML tags and it's not verbose at all. The templates are easily readable.
Pro Encourages clean design through SRP
One development pattern used frequently is to create a "high-level" widget rendering a group of HTML tags, attribute values, and content to support a single use case, then decomposing that into domain-relevant smaller widgets ("nav bar", "user menu", etc), which in turn would be decomposed into smaller widgets, This eventually leaves you with a set of "leaf node" classes encapsulating a single tag with specific attributes and content rules; "helper" widget classes that encapsulate commonly-used configurations of the leaf widgets, with possibly multiple widgets increasing in scope up to an entire page-level widget.
This also encourages the use of composition over inheritance; while each widget class must subclass a Fortitude (or Fortitude-derived) base class, the use of inheritance in your own widgets will tend to be quite rare. Typically, this will shout at the maintainer, "I'm a variation on Widget X", resulting in widgets that are by and large loosely coupled and highly cohesive.
Pro Encourages business-domain-fluent class usage
Fortitude widgets can either encapsulate a single HTML tag, appropriate (and validated) values for attributes, and content, or they can compose multiple such widgets as a single, domain-language-friendly unit; for example, "navigation menu", which might involve a container div, a list, and list items confirming to various formats (for actions, separators, etc). This is textbook use of the interface-segregation principle.
Pro No paradigm shift between views and any other part of your app
Fortitude implements "widgets"; Ruby objects that encapsulate one or more HTML tags, with additional support for the view/app as a whole. By virtue of being Ruby classes, these widgets can use all the techniques used in any other Ruby objects in your app (composition, inheritance, etc), making it easy to develop working code rapidly.
Con Bad Performance
The rendering time with haml is slower than its competitors.
Con Whitespace sensitivity can be problematic
Haml uses indentation to define structure, rather than closing tags. Though this, in most cases, makes code more efficient to write, it can also cause problems.
Being off by one space can cause an error or change the structure of the code.
Con Still young
Fortitude is still a relatively young project. Being still in beta release it hasn't been documented fully and may still have bugs even though it's tested extensively.