Adding another good talk on the subject: https://www.youtube.com/watch?v=NoaxsCi13yQ

Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.

It's becoming more and more common. Check this out:

http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...

Having the HTML and JS in the same file makes sense, since the HTML and the DOM manipulation code (which is what you usually see in the .jsx) tend to be tightly coupled; when they are, putting them in separate files really only gives the illusion of modularization.

Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.

[edit]

Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.

I agree with you, however the only way to really componentize (decouple) your css from the rest of the webapp is to use the shadowdom.

In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom

Or you could use CSS modules: https://github.com/css-modules/css-modules

It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components.

That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.

There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.

If you're using BEM, then in my opinion, styles in React are the logical conclusion. Using CSS means having 2 files per component, Button.js and Button.scss. If you want to share styles, then you can simply import an object. If you want to darken a color, you can import a function. And so on.

So what about caching and rendering? So I imagine that if I render 200 buttons that have inline style it would be slower if I load one stylesheet and 200 HTML tags.

And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles.

I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.

You're mixing two different problems. Just because you write your CSS in JavaScript doesn't mean you have to deliver them as inline styles. [1] [2] [3]

CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem.

[1]: https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS

Thanks. This solves a lot in my head. Nice references.

See Michael Chan's presentation:

https://www.youtube.com/watch?v=ERB1TJBn32c