[namuol]

Like most CSS tooling, this is a treatment for a symptom of an underlying disease: the inherently global nature of CSS[1].

Rather than "blob" all your CSS together, and then "de-blob" it, why not build your CSS dynamically based on what components your app is using?

[1] I strongly encourage you to watch this talk: https://vimeo.com/116209150

[emitstop]

For many reasons, namely that we've already solved most of these "problems" years ago with simple concepts like OOCSS, SMACSS, and BEM. I suggest taking a look at this rebuttal. http://keithjgrant.com/posts/against-css-in-js.html

The reasons people are running into problems with global css scope is because they don't understand the basics of how to write effective and maintainable CSS. Seems like many front end devs nowadays grew up with css hand-holding libraries like bootstrap, and can't seem to wrap their heads around completely necessary things like taking account for CSS specificity and how the cascade works and how to use it to your advantage.

[grumblestumble]

The way methodologies like BEM and SMACSS work is to acknowledge that the cascade never works to your advantage, and avoid it entirely.

[emitstop]

The methodology gives you the tools to have control over the cascade. You cannot avoid it entirely.

Edit: Also the point I was getting at was that cascade is a useful and powerful tool, just as the methodologies for controlling it are. We will also soon have a property that will eliminate the cascade entirely... all:unset;

I just think the problems and solutions listed in the talk are either non-problems or are things that could be solved in superior ways. And that it introduces more problems and limitations than it solves.

[moretti]

We've been using inline styles in our main project (built with React), but we recently deciced to move to css modules:

https://github.com/css-modules/css-modules

https://medium.com/seek-ui-engineering/the-end-of-global-css...

Inline styles are great, but they don't support basic features such as pseudo classes/elements, so even implementing simple components like buttons was cumbersome.

With latest version of webpack's css loader you get css scoping (you no longer need to add lengthy prefixes to all selectors) and you can also use additional loaders for post-processing your styles (we use a lot of postcss plugins such as autoprefixer).

Have a look at this example:

https://github.com/css-modules/webpack-demo

And here's a great comparison of the main CSS in JS techniques:

https://github.com/MicheleBertoli/css-in-js

[bpicolo]

Because it slows down your app by a relevant amount.

Edit: I see we're referring to inline styles instead of requirecss. In that case, it's because code reusability becomes a pita and you bloat your JS.

[Udo]

There's another way besides inlining and requirejs. In cases where you're doing server-side programming anyway, you can just have the server inject view-specific <link> elements pointing to individual CSS files as needed - augmenting the site's core CSS file. The downside is more requests to fetch those files, but after the first time you can take advantage of the browser's cache. As long as you keep the number of extra CSS files reasonable, this method costs almost nothing.

A variant of this is where you compile one CSS file from many view-specific ones beforehand. The advantage is it'll speed up things on the client side and the programming overhead is relatively small if you're using something to generate CSS anyway.

[marcosdumay]

> In that case, it's because code reusability becomes a pita and you bloat your JS.

Does it? Last time I had a bigish web project, I was starting to inline everything (CSS and Javascript), and had my backend language deal with DRY. It even solved the problem CSS people use CSS generators for. As a rule, both CSS and javascrit suck for organizing content.

But then, I declared that project dead, and didn't wait to see the consequences of organizing things this way. So, somebody may have a much clear understanding about why that's wrong.