At Commercial Progression, our development team tends not to use bulky modules like Panels or Display Suite without a reason that justifies the overhead. Those decisions (which we revisit frequently) lead to a particular site workflow, which we refine over time.

One Drupal design pattern I used on a recent site led to:

Entity "view modes" without ds

Small reusable modules to do Views-like things outside of Views

Displays of aggregated content controlled through the native UI

It took a bit more work the first time, but I'm excited to use it on the next big project.

Why do this?

Views is full-featured and highly-configurable. You can create views with any number of fields, format each field individually, relate content to other content and then pull the related content in and format fields from that too, filter results based on URL -- all kinds of stuff.

Drupal has a native way to choose which fields to display and format the results, though. And the core Content Type "Manage Display" is easy-to-use and quite extensible. There's an appeal to being able to use "Manage Display" over wrestling with Views.

On the other hand, "Manage Display" does not have all the neat options out of the box. It does simple things quickly and easily. Getting it to do things that Views can do via the UI can often mean writing a custom module to build a new field formatter.

However, you can use rendered entities in Views in multiple ways. If you want a hybrid of Views with fields and rendered entities in custom view modes, you can do that. It remains a flexible way to build sites.

One big appeal of using rendered nodes consistently throughout the site is that you can theme once and ensure a consistent design language is used throughout the site. This requires some forethought when it comes to classes and templating, but is immensely useful when it's all set up.

View modes and templating

Adding view modes in a custom module is super easy: