The Slim syntax does not require many special symbols that make it hard to read. Instead it's very clean and readable even for people who have not worked with it before.
Slim is actively developed, with new features and bug fixes being released on a regular basis. Issues are addressed quickly, and Slim continues to increase in popularity.
Slim's documentation is well organized and detailed, every concept is thoroughly explained and it is very helpful for both advanced users and beginners.
Slim allows the developer some control over how the syntax is written. It can be written without closing tags, instead using indentation. Or it can be written with closing tags, like standard HTML.
HTTP Streaming is a technique that keeps a connection between the web server and the web client constantly open. When the server has new information, it's immediately pushed to the client.
This technique is used to considerably increase loading times, because using HTTP Streaming the web app can start rendering parts of the view that do not require any complicated calculations (for example CSS files) immediately.
But to use HTTP Streaming in a Ruby app you need a template engine that supports it, fortunately Slim fully supports HTTP Streaming.
Slim's use of indentation in it's syntax and the fact that it doesn't use any HTML tags can make it seem a little strange to designers not used to this kind of syntax.
Since ERB is included with Ruby out of the box, there is no additional installation and setup required. The fact that it's included by default in Ruby, a lot of projects use it.
ERB is a way to embed Ruby into plain HTML, which means there is no need to learn a new syntax for HTML. This makes ERB fast to learn, and a great option to use on projects that have multiple developers/designers.
ERB's interpolated tags are very familiar to developers who have worked with PHP, ASP or JSP, even though they may not have any prior experience with Ruby.
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.
For example
This:
<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
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.
Liquid templates are secure out of the box. They can be used for applications where users can edit the appearance without allowing them to run any server-side code. Liquid does just that without any needed configuration.
Liquid has some known issues with boolean algebra when it comes to some advanced expressions.
Liquid::Template.parse("{% if false and false or true %} foo {% endif %}").render
# => ""
false and false or true
# => true
It seems that Liquid simply parses from left to right, and if it finds a false and X it immediately returns false.
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.
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.
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.
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.
Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari