>This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app.

You just handle it the same way you handle any shared code. You can keep files in a file scope, in a package / folder scope, or in the top-level global scope (in a small app that's totally fine). But removing globals-by-default removes a lot of "gotcha's" from working with CSS.

What are these gotchas if I may ask? Have you got experience with BEM?

Uhm.. Having to use BEM is a gotcha.

Why don't you write all your applications code in a global scope and just use a BEM-like naming scheme for your functions?

Globals are hard to name, so we use things like BEM [0] as a good naming convention to mitigate human error. CSS-in-JS is nothing more than an automatic BEM. I wrote down some thoughts on this today [1].

[0]: http://getbem.com/

[1]: https://medium.com/@jdan/css-is-fine-its-just-really-hard-63...

You should still use CSS and general programming best practices even if you define your styles in JS. For me, the big win is that I get access to proper variables, constants, dead code elimination, minification, template strings, destructuring, spreads, real computed values etc. out of the box and in an language I'm very familiar with as a programmer. That it eliminates half the build toolchain is also a plus.

In some of my projects I have 2 scopes: A framework scope and a component scope.

The framework scope has all the composeable classes and standard forms like lists, shadows, colors, grids, cards etc.

Then, when the framework doesn't cover everything, I use component scoped css to complete it, without having to worry about a naming scheme like BEM. It just makes things easier when you have css that is really only relevant to one component. Just like programming, I can always make the code abstract and move it up to the framework.

What is the advantage of bringing your styling into javascript to do that?

I do the exact same thing (I don't use BEM either) by isolating specific component styling to it's own SASS file.

The parent post as more about component based styling then css-in-js.

As for css-in-js, there isn't much of an advantage to using it vs importing sass files as scoped.

With Sass you get:

- Familiare Syntax

- Avoids inline styles

- All benefits of the Sass community

vs with css-in-js you primarily gain:

- Dynamic and regular styles together

- One less compiler dependency

- Benefits of full JS for style generation

So I think this really depends on the project and your preference, I don't think there's a massive benefit either way.

Can I see how you setup webpack to parse individual sass files imported into components?

CSS-in-JS doesn't mean you have to inline everything in the component file..

You can totally create a style library and include pieces of it as mixins for the styles of each component.

> It'll be awhile before you run into the limitations of CSS that Facebook is running into.

Or until your designer wants the corporate website and the internal dashboard to have buttons that look different.

Why would my corporate website be sharing the same codebase as our product app?