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.
Comments
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?