I struggle with articles like this because it groups all CSS-in-JS tools together, lambasting them all for the sins of some. Most CIJ tools author in a similar way, but their output can differ greatly. In fact, some CIJ tools spit out plain ‘ole CSS, with zero impact on the final JS bundle.

Addressing some of your points:

CIJ does not mean you don’t have to learn CSS.

This is obvious and I’ve yet to run across a CIJ tool that makes the claim that you no longer need to know CSS. Any CIJ tool I’ve looked into or used had a syntax based in or around CSS/preprocessor, necessitating CSS knowledge.

CIJ is an additional layer of abstraction in your project.

Yes… as is virtually any library or tool in the front-end sphere. CIJ’s can be a useful abstraction and no, they don’t complicate debugging CSS “code”.

CIJ does not help to communicate inside the team.

Sure it does, arguably better than any CSS convention. With most CIJ tools, I know exactly which files to change to get the desired effect and I have the assurance that I won’t be impacting any other components with my change. The styling syntax in the CIJ is still likely CSS based, so anyone familiar with CSS shouldn’t have any trouble.

CIJ approach makes your code even more tangled.

This is flat out wrong. Using a CIJ tool makes it much clearer where my styling code is at and to which components it applies. In fact, that’s arguably one of the best selling points for CIJ. The Separation of Concerns (SoC) principle applies to the final output that a user sees when visiting the site/app. It should not be twisted to mandate how a developer chooses to author their code. As I mentioned before, there are CIJ tools that author one way and output another.

CSS is a purely declarative language; for that very reason it is so powerful. But CIJ tends to be imperative. We are losing here.

WAT? CSS is not a programming language.

I do agree with your thoughts on the Shadow DOM. It’s the ideal answer to our modern CSS woes. The problem with it’s slow adoption is it’s poor browser support and the extreme difficulty in trying to polyfill it. Had the Polymer project taken off, it’s possible native support would’ve sped up, but vendors are certainly dragging their feet on it.

Angular 2+ has some cool style encapsulation stuff that takes advantage of the Shadow DOM when it’s supported and then can emulate it when it’s not supported, doing something very similar to CSS Modules.