Puck philosophy on components

[napter]

Hi -

What is the puck philosophy on having batteries included when it comes to components?

For example the grid and flex components are available in the demo app but not part of the core project. Is there any interest in moving those, as well as adding more such as rich text editing, and other layout components?

If not, what about having a sister package with a large pick-and-choose set of components to help puck be a better page builder out of the box. This would encourage more component contributions.

I am planning to expand our puck implementation but I don't know if you want this approach upstream.

[FedericoBonel]

Hey @napter! Sorry for the delay.

The components used in the demo are just for demonstration purposes and aren’t distributed as a package.

This is because we don’t want to impose any specific opinions on how your pages should work or look. A lot of people already have their own set of components or design system, and are just looking for the visual editing.
Even if we were to include them to the core and tree shake them, a lot of people would wonder why they need to install a set of components they are not using.

It’s also a matter of maintenance overhead for us right now. We are considering adding component config packages in the future, but it’s not currently a priority.
Personally, I think it would make the most sense to offer them as part of the ecosystem (another package) via tooling that drops them directly into your project, so you can edit them freely, similar to how the shadcn/ui CLI works.

If you want to develop a component package for it, feel free to let us know and we'll feature your package in the awesome-puck repo.

[napter]

I understand that and that definitely makes sense for things like editors and headers. However, I think pure layout controls may make sense as part of the core repo. If Puck is intended to be a drag and drop editor, having the ability to determine where things land using grid, flex, or other is useful no matter what design system is used for visual components. Puck does allow for vertical stacking out of the box - why not expand that to other layouts?

@FedericoBonel what do you think?

[FedericoBonel]

Hey @napter! I understand your point, but there are a couple of things to keep in mind:

• While Puck is often used as a page builder, it's fundamentally a visual editor. That means many people use it for things beyond traditional page building, for example: PDF builders, document editors (like Word), image editors, video editors, email builders (which are super limited on styling support), etc. In those contexts, components like Flex, Grid, and web-specific terminology don't really apply or make sense.

• Even within the page-building world, many of our users build integrations that abstract away those more "developer-focused" layout options. Their end users often aren't web developers, and in many cases, they're not even designers or technical users at all. For them, terms like “Flex,” “flex-grow,” “flex-shrink,” or “flex-basis” are confusing and unnecessary. They just want to drag elements into the canvas, pick a layout from a list that just works, and focus on their content. They don’t want to learn web jargon.

• In other cases, this kind of web-specific language and low-level control is useful, but users already have their own styling libraries and theming systems they'd prefer to work with.

The main issue with the proposal is that Puck needs to stay flexible to support a wide range of use cases, many of which have different needs and constraints, some that we may not even be aware of yet. If we start introducing opinionated layout components or APIs that lean heavily into page-building patterns, we risk narrowing Puck’s scope. That either limits its usefulness for non-page-builder use cases or forces us to maintain many different sets of component libraries for each domain.

The best balance we’ve found so far is to offer opinions on the visual editing side, but stay unopinionated on the integration/component layer (since we don't know what you might need for that). That’s why I do think it makes sense to ship optional component config packages (since people do ask for them), but not include them in core. If you need them, you can install them. If you have a more custom or niche use case, you can bring your own.

Does that makes sense?

[napter]

It does, thank you for the explanation!