Add comparison with styled-system

It is not quite fair to compare these two tools as they are different. I’d like to have this section to list the differences and help people understand when to use which, or both. The outcome of this thread will be evolved into a separate page in the documentation.

What:

Need to add a comparison between Atomic layout and styled-system.

Why:

Two solutions seem similar at first glance, and it’s fair to let developers know the difference between them, to pick the right one for their needs.

How:

1. Descrive difference.
2. Include code examples, where applicable.

[kettanaito]

Hi, @Hermanya. I absolutely love your comparison and I was reading it with so much thrill! The way you highlight similarities and differences is constructive and practical, love it. Thank you!

Atomic layout has a way to go, a bunch of API to refine and introduce. I’m glad to see some pain points that I’ve experienced myself, and to know that we have proposals to solve them. To be frank, I think that the comparison with more mature solution is too early to make, but it’s handy to have since it’s a common question people ask. I will add my comparison once I gain more experience with styled-system.

I will briefly go through some of your points to keep this thread updated about things that are likely to change in the future releases of atomic-layout.

Shared responsive behavior

And funny enough at first I was upset that atomic-layout does not automatically integrate with my breakpoints from styled-system.

This is crucial. There are two steps to perform to address this:

1. Unify breakpoints usage throughout an entire application (#132, #148)
2. Define breakpoints and provide them to styled-system and atomic-layout correspondigly. I don’t quite share the array-ish way of providing viewport-based values, as I find it non-intuitive and an being too library-specific.

API, prop names, and conventions

Another thing that could be better about atomic-layout is the API.

That’s true, some prop aliases used in atomic-layout may not be the best. I think #126 should fix that problem, allowing to 1) specify your own aliases, 2) refactor existing ones, making them more spec-compliant.

Template-less composition

But I found myself in constant need to come up with names for these wrappers. (context: usage of render prop in Composition returns named area components that may collide with your components).

Try Template-less composition. It’s not required to always use render prop with Composition. So you can omit namespace collision by render children as-is:

<Composition
  templateCols="250px 1fr"
  templateRows="100px 200px"
  gutter={20}
>
  <header />
  <content />
  <footer />
</Composition>

Children of composition still abide by the CSS Grid you create around them. Theoretically, you can also use areas and provide component-ares mapping by yourself, instead of using a render prop. I need to mention, however, there is more to the render prop than just areas mapping. It also determines conditional areas and automatically wraps them in media query placeholders for you. So manual replacement for render prop would not be equal in behavior.

I’ve opened an issue for namespace collision (#154), so everybody is welcome to contribute. It would be great to resolve this, as I can feel the pain around that.

---

Overall, I want to make atomic-layout combinable with styled-system, or any other solution. I don’t see a reason not to do that, as its primary concern is spacial distribution. Please feel free to tell me your ideas on Discord, or via GitHub issues. Your feedback is welcome, as always 😃

[Hermanya]

Thanks, I missed that.