I think we agree here. The argument I am making is that spacer components that introduce DOM bloat can negatively impact large apps, especially on low power devices.
A layout component does not have to introduce DOM bloat, it could apply layout directly via CSS to it's children. Layout components in this regard are incredibly helpful.
You can, however the lack of constraints on the spacing can make it difficult to match strict design systems. The dependence the spacing creates on the parent & child dimensions can lead to undesirable edge cases as well for dynamic/responsive content.
Clever, but this smells like a performance anti-pattern. Adopting this means you could, at worst, add 4 spacer divs per component. While most sites may never really feel a sting, for complex apps where reusability is a larger concern you've doubled to quadrupled the size of an already large DOM and you will be hit a death-by-one-thousand-cuts situation.
Now you've got more...
- html over the wire
- html to parse for first render
- DOM nodes to mount/unmount
- memory usage from excess DOM
- costly layouts due to extra nodes
- lighthouse complaints of an excessively large DOM
Otherwise a clean approach. Perhaps it could be solved at compile time or some other jsx -> CSS abstraction to maintain DX.
Love the activity in this space. We are on the lookout for a tool like this with built in runtime performance monitoring (frame jank, composited layer size, long tasks, component render times, etc). Would happily pay for a service that could do so.