[Semiapies]

CSS in JS is not an inherently bad idea, but I haven't seen a good implementation, much less one as good as a CSS preprocessor. CSS done in React abandons all that's powerful about CSS in order to do glorified inline styles.

Look at the example. Imagine that being one of dozens or hundreds of components in an app. Then imagine trying to re-style the app from a flat-looking interface to whatever's trendy next. I'd much rather do that with a LESS file than muck through however many JS files that would take with this.

[seivan]

You're missing the idea here. The idea is that the front-end engineers don't have to deal with styles anymore.

They can just take a <Tab><Item/><Item/><Item/></Tab> and expect those components to be designed inside of the components themselves.

This is var more similar to how iOS handles design. You have your own custom views with their own style defined, obviously on some you can override them, but usually they are defined inside the class itself.

It makes sense for Web to take this route, given how hard it is to design on the web compared to iOS. At least for me :)

[clessg]

I suppose I look at things differently, because I use the BEM/SUIT methodology. There is already a logical one-to-one mapping between most BEM components and React components, so the effort required to change everything would be roughly the same.

The point of using inline styles isn't to be hip: it fixes most problems caused by specificity wars, global selectors, monkey patching, code bloat, dead code, and indeterminism. I agree that there is yet to be an implementation that is perfect, but there are some very smart minds working on this problem at the moment.

[NathanCH]

My issue is that the problems you listed are solvable if you write good CSS.

I mean, specificity wars... isn't that one of the first things we learn to avoid when writing stylesheets?

[clessg]

Right. So long as you follow sound architectural practices and be careful to not override global selectors, you will achieve most of the benefits of inline styles. https://github.com/postcss/postcss-bem-linter is a godsend.

However:

* Your components will still be spread out among separate files. Button.js, Button.scss. Icon.js, Icon.scss. Just like it doesn't make sense to separate inherently coupled HTML and JS, it doesn't make sense to separate inherently coupled HTML/JS and CSS.

* You have to use two separate programming languages unless your app is simple.

* SASS and LESS can be really problematic. They have ambiguous syntax and are non-standard. There's 9,001 ways to import in LESS. They look like programming languages, but they differ in confusing, bug-prone ways. SASS and LESS's variable resolution are different and confusing. And math is whitespace-sensitive. Yes, whitespace-sensitive math.

* Another build step.

* No easy way to get values statically from CSS files. Instead you have to use comments like "IMPORTANT: keep this value in sync with Button.js!". And if you forget, you will have a difficult-to-debug problem.