[desertedisland]

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?

[room271]

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.