Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhat is the best alternative to Liquid?
Top Pro
Top Con
Top Pro
Top Con
Top Pro
Top Pro
Top Pro
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 See More
The dependency container schema of Slim is one of the biggest PROS and CONS of the framework. It is true that this schema brings so much flexibility to add anything, but another thing that is true is that you need to have strong bases of patterns, and an extensive knowledge of your libraries to convert it into a Slim dependency. See More
Rack is an interface used in Ruby frameworks used to group and order modules, which most of the time are Ruby classes, and specify between them. Slim uses a simple concept for it's middleware. By wrapping HTTP requests and responses it unifies the middleware into a single method call. See More
While it's true that Slim is a microframework, it's still too minimal. When used for throwaway projects or simple prototypes, it's perfect. But in the long run, it becomes less and less useful and you end up in implementing a full custom framework in trying to tackle all the missing features. See More
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. See More
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. See More
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. See More