Hacker News Reader

Comment by Kiro | Hacker News Reader

> There's always a specific percentage of styles being shared between components.

I used to think that but nowadays I very seldom come across a situation where sharing styles make sense. I'm trying to make my components completely isolated, styles included. I'm doing CSS-in-JS and if I really need to share something (say a primary color) I import it from an explicitly shared module called "colors". This leads to some duplication but when I change something I know it will only affect that component.

View on HN

After using tachyons (http://tachyons.io/) I've gone the complete opposite direction. While tachyons takes it to an extreme, I found having many small classes that (generally) do one thing, then composing those classes in the HTML, is much nicer than giving each element one "semantic" class name and hiding all the complexity in the CSS, with the large file size and many duplicate rules that approach brings.

You are then not scared of changing existing classes, as they are so simple. In fact you rarely have to change them after writing them the first time. Often you can build a whole new component without writing any new CSS.

It works especially well with components, as it's OK if the HTML is "noisy" with many class names, as generally you're not dealing with large chunks of HTML at once.

I actually take it one step further and have classes such as `border-1-px border-dark border-bottom standard-margin no-margin-top`. Seem weird at first but combined with flexbox (if your target is the evergreens) you never overwrite and you got one stylesheet for pretty much all of your projects. It's a real production boost.

Really not a fan of CSS-in-JS. I like to keep my components JS+JSX only.

That might make sense in your case but, honestly, it runs entirely counter to the reason CSS exists.

A big motivation for the development of CSS was to get away from the situation in the 90s where elements would have their own styling - complete with duplication - embedded in them using (sometimes non-standard) attributes.

The situation back then made it a nightmare to apply a consistent style across a site, as well as bloating pages at a time when most people accessing the internet at home were doing so using a modem.

Most people don't use modems any more, but many of them do use mobile devices, often with high latency connections depending upon network coverage and contention. In other words unnecessary bloat is still a problem, and that original motivation for CSS is still valid.

I disagree. I don't care what the motivation was since I believe CSS with cascading styles and global declarations was a failure to begin with.

I've built many sites using both traditional CSS, with standards like BEM and now CSS-in-JS and this is the first time it actually makes sense. I have yet to encounter a case where I miss the old way of writing CSS.

I think applying "consistent styles" is a fallacy. It sounds like something you want but in the end it becomes a nightmare to maintain once you start sharing styles all across your app. What happens is that you overwrite stuff instead of rewriting because you don't know what rewriting a certain style declaration will affect.

My main point however is that there are very few styles that actually make sense sharing between components. I gave one example; colors, but what else? Take stuff like padding and margin for example. It feels like they are something you want to be standardized but usually in big projects they become extremely context dependent and as soon as you need to deviate from the standard it becomes a headache.

The bloat argument is invalid if you use a proper CSS-in-JS lib which compiles the styles to CSS classes.

Reply on news.ycombinator.com