Slim vs Fortitude

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 is minimal and that is a good thing if you want to start from there. It can be easily extended and even supports popular packages that are used in Laravel (like Illuminate\Database (eloquent)) for example.

REST fans will love the REST based architecture.

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.

Contains classes for managing requests, responses, cookies, logging, views, HTTP caching, and more.

Slim doesn't demand that you stick to a fixed folder structure. As long as you load Slim the right way you can do anything from there the way you like it.

Paired with swoole it's a micro service powerhouse.

The Slim Framework is open source and is released under the MIT public license

You can add any dependency, package or class that you want to use as a contained dependency.

In Django most things are abstracted, you just call some function or class without knowing how they were built, but with Slim, you end up understanding the way some abstract functions and classes are built.

Slim supports code hooks for executing functions at different points in time during the application's lifecycle.

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.