Some folks want a unified language of the web instead of CSS, HTML, and JS. It's increasingly looking like JS will just eat the other two.— Henrik Joreteg (@HenrikJoreteg) May 28, 2015
So What About CSS?
This is a really bad idea. Where, with JSX, my reaction was, “Yes, finally!”, my response here is quite the opposite. I’ve had a hard time articulating exactly why I respond this way, especially on the length-constrained and fast-paced atmosphere of Twitter, so I’m setting out now to articulate my reasons here.
Before I dive in too deep, I do want to say I have interacted some with React Native folks on Twitter regarding this. I acknowledge that their work is primarily in the realm of native applications, not in the context of the web. I think this has ramifications for their use case that I myself am not familiar with. My thoughts may be applicable to them, and they may not; I’m not well-versed in that world enough to speak to them directly. But I do hope others take note of that distinction before they clamber to repeat these practices on the web.
We Are Not Solving the Same Problem As Before
If you use the best practices of OOCSS, SMACSS, or BEM, you will not need to edit the CSS every time you edit a page. In fact, once you have your basic building blocks of CSS defined, you can build out all sorts of things in the markup before you need to touch the styles again. Far too often, developers write their CSS and HTML together, with selectors that mimic the structure of the DOM. If one changes, then the other must change with it: a tight coupling.
If your stylesheets are well organized and written with best practices, there is no bi-directional dependency between them and the HTML. So we do not need to solve the same problem with our CSS that we had to solve with our markup.
Beware Framework Lock-In
All or Nothing
The problem with that is, CSS takes care of some things cleanly for us that you are probably taking for granted. This is helpful for fonts in particular: The default font size, the font face and line-height, and the color of your font are all inherited silently from one of the topmost elements on the page. Do you want to explicitly set these things on every single component you build? Because you will have to.
Not only that, but if you distribute your component, the users of that component need to be all-in on the same paradigm, as well. Your component sets inline styles, which means they can’t be overridden without
Missing CSS Features
I think there is a place for a few inline styles in a React component. I’ll admit I’ve had to do it a few times. Most often, though, it is because I need to accomplish something that can’t be done in pure CSS (yet), such as animating from
height: 0 to
You also lose the ability to do some other things, as well, like media queries and fallback values for older browsers. Unless you want to start browser sniffing and adding conditionals around your styles. Again, this is adding more responsibilities to your components that otherwise they would not have.
In Defense Of CSS
At this point, I have to ask: what problem are we trying to solve? There is a lot of baggage and many unknowns if we start doing CSS-in-JS. We had better have a damn good reason before we go down that road. Christopher Chedeau, in the original slidedeck that introduced this idea, outlines seven “problems” with CSS. The thing is, they are solvable problems. If we as web developers just understand CSS better, and take the time to learn modern best-practices like SMACSS and BEM, these issues almost entirely dissolve, especially at the scale most of us work at. Don’t get me wrong; he does make some good points that are worth discussing, but I believe we have at least partial solutions for all of them (some of the latest proposals to the CSS spec help, as well). If you want to discuss those points directly, feel free to ping me on Twitter.
It’s time to truly learn CSS, because that’s our real problem. And that is a problem we can fix.
Update: I have written a follow-up post: Into the Future of CSS