Hacker News Reader

Comment by room271 | Hacker News Reader

(I work on this team at the Guardian but views my own.)

You are definitely right that there are still challenges around how you structure and re-use JSX components.

However, our primary motivation with CSS-in-JS was to achieve decoupling between different parts of the page when it comes to CSS. I.e. if I change this part of page A, will I break other parts of the page? Or even, will I break something on a completely different page? By scoping styles to components, CSS-in-JS helps avoid these kinds of issues. Of course, it introduces its own complexities.

This is really not an academic concern on a large website with daily commits by developers often from different teams and not necessarily experts in CSS. Only last week I had to fix an issue of this kind.

View on HN

Hmm... Don't take this the wrong way but the point of CSS is that it can be modified by people that are good at, you know, CSS - a class of people that generally does not include your average java / PHP / javascript developer.

I agree entirely with 'scoping styles to components' but css in js is a massive step backwards when this can be accomplished much more simply by maintaining a less / sass / css file in the same folder as the js and importing it.

My two cents, as a contractor who is paid to fix other people's code: there is an aspect to semantic HTML which is the descriptive nature of attribute class names. This is completely destroyed by css-in-js.

In short: I can easily track down the styling (and probably the component) in the code based on an attribute classname. How on earth do I do that when every single class is named some combination of 'R23RG67ED'? I know there are things you can do in Webpack to create some sort of descriptive name ('component_1-wrapper_2-div_3-my_wacky_component_5-GEWRCER anyone?) but a) nobody does this and b) if the only reason we're implementing css-in-js is for issues of scope, surely this is not a step forward?

Hey thanks. I think probably our experiences are just different here. I've found that convention (one css file next to the JS component in this case) is sensible but can break down over time or with larger dev teams. In these cases, I tend to prefer a technical constraint over convention when there is a choice between the two and it's for something important. On tracking down the styling, we haven't found identifying the relevant component where CSS lives difficult in practice but I can see that might not always be the case.

Edit: just to add, the comment in this thread https://news.ycombinator.com/item?id=19608498 does a much better job of explaining all the benefits of CSS-in-JS.

Reply on news.ycombinator.com