We announced a new Drupal module called Stacks a few days ago.  Since we launched the module we’ve gotten some thoughtful questions from the Drupal community about why we built Stacks given that is appears similar to Paragraphs.

The short answer is that we love the Paragraphs module and we strongly considered extending it. Ultimately, we determined that the problem that Stacks is trying to solve is fundamentally different from the one paragraphs addresses. Given the different approaches and requirements, we needed a custom code base to work from so built our own modules.

Longer answer below.

We love the paragraphs module and admire the work that’s been done on that project. There are a lot of great ideas and concepts that we drew from when building Stacks.

I guess the best way to explain our thought process is with the Stacks origin story…

A few years ago, our team began a process of evaluating how we built Drupal sites and realized there were a few key problems we needed to solve:

• Wrangling the Drupal frontend through components and reusable styles (an approach similar to Atomic Design)
• More efficiently focusing our development efforts so that we weren’t reinventing the wheel with every client project.
• And finally, making Drupal more friendly for our (mostly non-technical) clients

We did tons of research on the module ecosystem (including paragraphs) and piece by piece built out our new approach. One of the key things we kept coming back to though was our end clients’ experience. We love Drupal, but there seemed to be a disconnect with some of our end users.

After a good deal of discussion internally and with our clients we determined that we needed a few things that we couldn’t find elsewhere:

Opinionated Admin Experience: as mentioned above, Stacks is primarily focused on making a better experience for non-technical content editors. Adding a widget, reusing content and building complex UI had to be easy. We felt we could do this best by creating an opinionated design for the content admin.

Content Reuse / Content Library: core to Stacks is the concept of a reusable content widget. We’ve created a search/filter system for snippets of content that users have already used throughout the site – a feature we plan to build out further in the future. The goal is to create a content library that can be reused and extended throughout the site. We think of it as a Media module for your content.

Widgets: we wanted to give our users access to powerful functionality in a simple way. We wanted people to create things like donation forms, email signups, filterable content feeds and sortable tables of data straight from the content admin. To do this, we needed a robust widget concept.

We include two of these more robust widgets currently in Stacks – the Content Feed and Content List – with plans to add additional advanced widgets in the future.

Widget Bundling: we wanted to group similar widgets together in the admin. For instance, someone may have several calls to action on their website such as an email signup, a product for purchase and a place to follow their organization on social media. Instead of having three separate widget choices within the admin, with Stacks we might implement these all under the widget type ‘Call to Action,’ which would contain all three of the widgets. When the user selects ‘Call to Action’ they would then be able to choose the specific widget they want. We felt that being able to group these very different widgets categorically simplified things for the end user.

Theme / Template selection: many of our clients’ sites include widgets with the same structure but different layouts, colors, etc. One approach would be to wrap the widget in custom classes, altering the appearance visually. We found this to be too technical for most of our users. We created Stacks with a concept of themes and templates for each widget. This way, users can simply select from options presented to them in the admin rather than understanding HTML/CSS and how it relates to the content.

More advanced integrations: In addition to what is outlined above, we think you’ll continue to see separation between Stacks and Paragraphs through some of the features that we’re currently working to release such as:

• Frontend editing of widgets
• Integrated A/B testing
• Content personalization

When it came down to it, we determined that where we wanted to go with Stacks was ultimately different than anything that was out there, including paragraphs. We strongly considered extending the Paragraphs module, however, we determined that our plans for the admin UI, content library, frontend editing, A/B testing, Personalization, etc. would require us to create a custom module. We also realized that Stacks was meant to be a more all-encompassing solution than paragraphs. It’s more opinionated in how it handles the content admin and may not be the best solution for everyone.

We have been using Stacks for our client projects and continually developing new features. In 2016 we realized that we may have something of value for the Drupal community and the decision to release it to the public was made.

Whew, that was a long-winded response – thanks for reading! I hope that helps outline where we see the key differences and why we went the custom route. We’d love to hear any thoughts or feedback you may have about Stacks as well!