Completely agree - I find the current trend (and that's what I see it as) of css-in-js to be most disagreeable. CSS works fine without JS, or even better with SASS/LESS.

I both love it and hate it. I love it because a lot of the supporters, on the inside, hate it too. They've spent the last decade saying, ya gotta keep 'em separated. Now they have to say no, it is fine to mix 'em. And it's killing them to say it, but they need jobs, so they follow the herd.

But, yeah, other than that, it's a stupid idea.

CSS in JS isn't CSS. It's just SS. It ignores the best part of the language; the cascade.

Or the worst from my point of view. CSS rots more than any other code in a front end codebase and the methods for static analysis are incredibly limited.

Refactoring and static analysis tools are incredibly limited or nonexistent for plain CSS or SCSS (when talking about the barriers between HTML and the stylesheet).

We do all of our new views and stylesheets using React, TypeScript, and Typestyle. As a result we can expose much controlled methods of theming and have a compiler enforced link between variables, selectors, and their usages. We can refactor easily. We can catch simple typos at compile time instead of runtime, and validate them more easily in CI.

> have a compiler enforced link between variables, selectors, and their usages.

That sounds interesting. Can you describe that in more detail?

The cascade was great for HTML in the absence of scope, which is to say in the age of documents. It's a reasonable approach to dealing with all the problems inherent in managing global state. But globals suck. In the age of components it makes little sense to cling to the cascade as if it were more than a means to an end.

1) it doesnt ignore it

2) anyone claiming not to have a single `style=""` attribute (which is almost as specific and 1000x less maintainable) in their code is lying

I will swear on my life that I haven't used a style attribute in the last five years. Since I started using BEM for namespacing I have had a very easy time keeping my CSS clean and maintainable. I won't deny others their opinions, though.

BEM is a decent convention for old-school, global document styling, in the absence of scope. But it's also manual, error-prone, and verbose, making it a poor substitute for actual namespacing provided by components. I sympathize with your resistance to css-in-js; I've been doing webdev since 1998 and only really embraced it in the last couple years. I'm reminded of quotes like "The difficulty lies not so much in new ideas, but in escaping the old."

Fair enough. I felt the same way about JSX when it came out so maybe I need to give it another look. :)

I think BEM was the point where I decided to give up and accept CSS in my JS.

Is CSS Modules considered to be "CSS-in-JS"? It does require JavaScript to import the class names, but the stylesheet itself is static. I personally find it to be a great solution to the scoping problem, and combined with Sass it's very flexible. Even theming is a cinch with a single shared Sass file with theming variables, or CSS custom properties.

Every CSS-in-JS library I've tried makes everything way too cumbersome with no real upside. I especially hate how they all spread my style declarations all over the place.

I can't answer your question, but after a lot of experimenting and reading I ended up with styled-components as my preferred solution if I were to go the SPA way.

It allows you to write your CSS inside the backtick js strings (template literals?) and then inserts/removes the relevant CSS as components are loaded/unloaded.

Personally I've gone in an entirely different direction (server-side everything, and simply diffing the HTML on the client when necessary), but if I were to build a proper front-end app, I'd probably go for styled-components.

The main downside is that the stuff needed to parse the css-in-js-string is yet another thing that increases payload size, but for an app it's not too bad.