Hacker News Reader

Comment by Wintamute | Hacker News Reader

I don't think this guy gets it.

In real life large web apps CSS is very coupled to behaviour and DOM structure. A large part of the advances towards _adaptable_ component-based code comes only when you let go of principles like DRY.

Let me put it this way, if I come along to change a feature in one of the 100s or 1000s of components in a project I _only_ want to think about the JS and CSS in that component's folder. I don't want to think about how that component exists in a vast web of generic CSS utilities and abstracted decoupled code. Copy and pasting CSS properties is cheap. Conversely overly abstracting your presentational code is a short cut to expensive CSS spaghetti.

It's about component encapsulation, which intimately includes its visual presentation. If you can't think of your component as encapsulated single unit then you might as well not be using components. And if you're not using components, then for the love of God don't use CSS in JS.

View on HN

> A large part of the advances towards _adaptable_ component-based code comes only when you let go of principles like DRY.

> I don't want to think about how that component exists in a vast web of generic CSS utilities and abstracted decoupled code. Copy and pasting CSS properties is cheap. Conversely overly abstracting your presentational code is a short cut to expensive CSS spaghetti.

You probably know this, but based on your phrasing I just wanted to point out that DRY isn't for mechanically compressing source code; it's for removing 'out of sync' issues, like causing bugs when we forget to update this copy of a procedure when we altered that copy.

Removing such 'conceptual repetition' makes life easier, since (a) we don't need to remember any couplings that need to be kept in sync (this is the "obvious" benefit), but equally importantly (b) if there are multiple copies of something, we don't have to worry about the other ones since they're not related.

It's perfectly fine if many similar chunks of code are scattered around a project, as long as they don't have to be 'kept in sync'. The whole point of "components" (/modules/packages/etc.) is to be self-contained, so it's perfectly reasonable to avoid coupling them together in a "vast web".

    Wrong abstraction < Redundancy < Elegant abstraction

In CSS if several components have similar styles it is often better to copy-paste because in future you might need to change those components independently.

You're right. I think we're on the same page. I was trying to get across the idea that CSS and visual presentation is a special case, peculiarly unsuited to DRY. Often visual features are only superficially similar ... e.g. at a certain stage in development the "Foo" component is superficially visually similar to the "Bar" component. If we then couple them together by both using the same CSS, but the implementation diverges as new features are added then we've given ourself a headache.

> Copy and pasting CSS properties is cheap

Why even bring that up? All 'CSS-in-JS' approaches have a way to reuse styles without having to resort of copy and paste.

That's what got me with it - the author states as if it's fact that best practice for CSS-in-JS is copy and paste, but I've never seen anyone advocate for that. Especially with Webpack etc, it's trivial to just import JS styles and re-use.

Sealed the fact to me that the author is biased towards CSS, without actually knowing anything about CSS-in-JS solutions.

See my new comment just above about DRY. Just because CSS-in-JS lets you re-use styles doesn't mean you should. Re-using styles is often an anti-pattern in large component systems.

Reply on news.ycombinator.com