Differences to Paragraphs / ECK

Same question(s) here!

I was wondering too. In fact, I also thought of field_collection which is in the situation to probably join forces with paragraphs instead of porting it to D8

+1 - The first question everyone is going to ask is how this module differs from and improves upon Paragraphs, and also probably Panels. If you do a writeup explaining the differences right on the module page, that would help a lot. Thanks for your work!

+1

Thanks for taking a look at Stacks and great question!

--------
TL;DR: 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.
--------

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!

This makes me sad.

I started the Drupal 8 port as a new maintainer to Paragraphs. We then spent a huge amount of time to understand what Paragraphs is used for and what its future should be. We went to events and presented our ideas at workshops, organised first sprints
http://www.md-systems.ch/en/blog/md-systems/2016/06/28/we-loved-drupal-d...

and then went to dev days and presented the progress
http://www.md-systems.ch/en/blog/md-systems/2016/05/31/future-paragraphs

People are excited about Paragraphs. And we have developed a strong vision
http://www.md-systems.ch/en/blog/business/2016/11/10/media-seo-and-parag...
In contrast to ECK, IEF, it is dedicated to Content Creation, in a composite environment. That clear dedication allows us to be opinionated and make a great UX. That sounds familiar, right?

We called for collaboration, and tried to make everyone aware of the idea that previously released something for Paragraphs.
http://www.md-systems.ch/en/blog/md-systems/2016/12/19/lets-collaborate-...
#2838275: [META] Collaborate with related modules

We even started to analyze everything ever published about Paragraphs and create an overview on our project home:
http://www.md-systems.ch/en/projects/open-source/paragraphs

Most recently, i presented at Drupal Mountain Camp Switzerland:
https://drupalmountaincamp.ch/sessions/content-experience-paragraphs
A blog post with most recent slides of Paragraph plugins, Experimental widget and Paragraphs Collection with atomic components... The blog post with the slides will be published soon.

Did you miss all that?

Miro - no need to be sad - we think Paragraphs is great and hope the excitement for it continues! The work you’re doing is very valuable and we’re excited to see the development continue to push Paragraphs forward.

A little bit more insight into why we built Stacks - we began development on what eventually became Stacks a few years ago to solve an internal problem. Over time it has grown into something that we thought would be useful to release to the community. As I mentioned, 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, after researching extensively, we determined that our development plans would require us to create a custom module. At the time, we specifically made the decision to harness the power of inline entity forms as the technology behind the UI, which to the best of our knowledge was not a part of Paragraphs. Since then, we realized that we needed Stacks to be a more all-encompassing solution, including things like A/B testing, personalization, etc.

As we continue development and release our upcoming features, I think you’ll see increased separation in the problem that Stacks is solving vs that of Paragraphs.

Our hope is that both Stacks and Paragraphs can co-exist and continue to improve the Drupal content editing experience in many different ways.

Does Stacks handle editorial workflows created through Content Moderation? I don't see any mention of it on the project page or your website's splash page.

Please also read through this discussion: https://www.drupal.org/node/2784931

I find stacks approach pretty aggressive. It would be same if you say: instead of adding to views or panels we write our own.

Stacks doesn't support revisions, putting it on par with what you get out of core (EntityReference) with a different UI on top. You really should have thought through your decision a little more before repeating history of having another reference field architecture that has to shoehorn on revision support.

And I just discovered the Bricks module that makes the same mistakes of leveraging EntityReference instead of Entity Reference Revision. sigh

I think you've outlined some great concepts here. However, it's a bit surprising that given your focus on the authoring experience you've failed to account for revisioning. Unfortunately, this isn't even worth looking at without support for revisions.

@damien Thanks for doing the research!!

@miro_dietiker, this makes me sad too ...
paragraphs versus stacks versus bricks versus ECK versus plain simple blocks

Why so much complication?

Right now I'm stuck as to which to choose ... not from feature or function perspective but rather which will live on in D9 and continue to have an eco system. hmm

@sajosh, thats a great question!

So far, I've found that ECK covers more than paragraphs, such as reusable content and even just data storage. On the other hand, Paragraph offers the slightly better UI and other layout features. Brick is not user-friendly enough. And Stacks lags behind with features like revisions.

My recommendation: ECK and if necessary paragraphs (because of layout functions and user experience). But you're right sajosh, selection isn't usually bad, but these different modules for the same requirement is not good.

THE MAIN PROBLEM:
This simple requirement is not included in the core. And the requirement is:
1. Create Field Groups which can be added indefinitely for content creation.
2. Simple and understandable content creation (Widgets/UI).

One of the biggest weaknesses of Drupal without contrib modules.

FYI Paragraphs has the submodule Paragraphs Library that lets you reuse paragraphs, thus avoiding the need for a whole extra entity system for those occasions you want to reuse a paragraph.

To keep everyone updated on where Stacks is right now. We are experimenting using Paragraphs and some supporting modules and an admin theme that extends seven to see if that is a better fit than the direction we took Stacks. We got the paragraphs setup to have most of what we liked in Stacks implemented in this setup with not too much custom php code. The library functionality and the experimental paragraph formatter works really well.

We are about to work on our first large build using this system, and we are going to use it as a test to see how it goes. But so far it is looking very promising. We learned a few useful tricks that create a really solid admin experience. I'm really excited to share what we learned, but I want to first see how things go with a real project. We will keep people updated on our progress.

As an FYI, if you currently use stacks, we plan on maintaining it on a minimal level (fixing major bugs or security issues), since we are using stacks on quite a few builds.

Interested to hear the results @chrisroane!

@chrisroane How are your trials going with your experiment? Will your updated system be available as a 8.x-2.x version of Stacks?

Do you maybe have some feedbacks about your experiences @chrisroane ?

We had launched that big project that uses paragraphs instead of stacks, and customized the different templates. It worked well for the clients needs.

These days we are noticing that most clients aren't needing as much flexibility as we were providing in our "stacks" type of approach. We end up doing most of the work in managing this content, and so we have started to implement a more standard paragraphs approach.

The problem we found is that it takes a lot of work to handle the different ways content can be displayed, which is usually overkill for most projects. We spend a ton of time setting up a system that isn't fully utilized. Is it cool? Yes. But we think it usually isn't necessary.

If you haven't used paragraphs, I would suggest taking a look. There is a lot of overlap with what paragraphs does with what we were doing with stacks, and you can easily add fields that change the output of the HTML. I hope that answers your question.