I see this a lot: that people creating CSS-in-JS libraries just don't know CSS well enough to solve their problems. I work with the people who created Radium. They made it because they are extremely experienced CSS developers and do understand what's wrong with plain old CSS.

I highly recommend watching this talk by one of the creators; it's kinda long at 36 minutes but answers all of your questions: https://www.youtube.com/watch?v=k3OF4A30jSQ

"Throw in CSS Modules" – that is indeed a decent answer today, and the creators of Radium love CSS Modules. But CSS Modules are what, 10 months old at most? CSS-in-JS concepts and implementations are more mature than that, and get you some further advantages like dynamic, runtime computable styles.

On a bit more of a positive note, I highly encourage people to check out CSS Modules. It introduces name mangling to CSS so you get 'locally' scoped CSS classes which you use by 'importing' them in your view component.

It's 'compatible' with any preprocessor, because it's working on the CSS itself. I think the cool thing about CSS Modules is that it makes BEM obsolete - that naming pattern is now essentially enforce at 'compile-time'.

Check out this article for more info http://glenmaddern.com/articles/css-modules

I was using Radium for a while, but switched to CSS-Modules and never looked back once. Its so much nicer, and you get to keep everything that CSS already has, including a sane readable dom and the ability to inspect elements (not possible with inline-styles when your output is all `style={...huge giant mess...}`). On top of that you still get to use your favorite CSS preprocessor if thats your thing. There's no comparison IMO. CSS Modules fix the scoping issues, and `composes: otherStyle` fixes the rest.

AFAIK Radium actually no longer generates inline `style={...}` attributes but `<style>`s at the appropriate places instead.

I agree CSS Modules are super neat, but I haven't really figured out a good way to handle cases where the cascade part of CSS is actually useful, like theming.

I like it a lot, but I had a hard time combining local CSS modules with external libraries (such as bootstrap, or a CSS for a plugin) in a previous react project.

I think what's driving the css-in-js libraries is actually a drive for better separation of different concerns (and the close cousin, better combining of the same concerns).

An idiomatic react/redux app will have dumb components which receive data as props, and contain zero business logic; they are solely concerned with presentation. Which is great! Big wins in terms of clarity, conciseness, maintainability, testability, etc.

There's just one exception though: The CSS is still in a separate file, but at least some of it isn't a separate concern at all. I have my custom CustomerTable component which contains all the custom presentation logic for rendering a list of customer based on their current subscription status, and which contains all the JSX for generating the actual DOM, and...none of the styles. But I still need those styles for the component to actually work! It feels weird, once you get used to React, to have 95% of the logic needed for a custom component in one file, and the remaining 5% in another file.

I think a lot of experienced React developers would really like something that was basically "JSX for styles"; some simple syntax that would just make their lives easier and let them create simple, dumb components that contain all the logic and code needed for rendering the components.

That being said, I don't think any of the CSS-in-JS libraries are actually quite ready for primetime, for the reasons you listed. We're currently using CSS modules (as described in detail here[1]), and finding it works really, really well, and just living with the mild annoyance of having tons of FooComponent.js, FooComponent.less pairs.

(Seriously, CSS modules are amazing.)

[1]: http://glenmaddern.com/articles/css-modules

Isn't leaving .css up to the presentation and components for the structure for the UI a better separation of concerns?

The hover problem does kind of suck--- as far as I know, Radium (and others https://github.com/FormidableLabs/radium/tree/master/docs/co...) tend to solve it by wrapping components with a component that tracks hover state. And moving the hover-state tracking into React isn't the _worst_ thing--- JS is meant to be in command of the interactive portions of websites, so it does kind of make sense. If your :hover is ever going to have to do more, like show or hide content, it'll have to be in JS anyway.

The "JS Fatigue" haters will be cobolt-maintence programmers of the 2020's, I don't pay much attention to them. Javascript has a lot of churn because we have a difficult platform & language to improve upon.

To nitpick just a little, not all content shown through a hover is controlled via Javascript.

Although, I discourage the practice of hiding/showing content based on hover states.

whats cobolt?, do you mean COBOL ?

I agree, it also makes React component much more complex thant it should. I've seen open-source components with dozens of props for the css and where 80% of the javascript code was actually just styling. I'm not sure what's the gain there versus something like Sass + BEM, except from making the javascript code way more unreadable.

Not to mention the mess in the html if it inlines the css.

Speaking as an outsider the modern sass and less frameworks look ridiculous in their complexity. variables and datastructures, loops and recursion and mixins all break the declarative paradigm.

Not to mention it's all working on top of a complex cascading rule-engine.

Pushing all that programming stuff into regular jsx and inline composible styles looks much more compelling if it's possible.

> What's wrong with just "plain old CSS"

Doesn't have namespacing and composability is difficult. It's a poor language missing expressivity. Javascript, on the other hand, has all of these. I personally just don't like inlining it because it looks bad in the Dev Tools and you can't simply edit a class and see the changes.

"Plain old CSS" is not plain old CSS: it's plain old CSS plus a pre-processor build step that you then have to integrate into the live functionality of your app.

CSS-in-JS just cuts out a whole swathe of tools and replaces them with what is essentially just JS. Even Radium is extremely limited, because just by inlining styles using pure JS most usecases are already covered.

Well, plain old CSS is just plain old CSS. There's nothing forcing anybody to introduce a processor, pre or post, into the mix if one doesn't want it.

Sure, but if you're talking about true "plain old CSS" then there are some huge issues that are going to come up in many situations. It's not a particularly comparable solution in terms of power, whereas pre/post processors are comparable with CSS-in-JS.

What exactly are these huge issues?

In the interest of DRY, if you search for "why use SASS" those reasons are what I'm referring to.