[rtsao]

I think the argument is that separation of UI components is a more true "separation of concerns" than separating CSS, JS, and HTML.

The implementation of a UI widget is ultimately a combination of CSS, HTML, and JS which are coupled to some degree, so by colocating them together, the component is easier to manage. But to do this effectively, you need some way to get around the global nature of CSS. CSS modules and CSS-in-JS are means of achieving this.

A good blog post about this topic is: https://medium.com/seek-developers/the-end-of-global-css-90d...

[kowdermeister]

> the component is easier to manage

But you can still keep CSS in a CSS file inside a module folder. SASS or any other CSS build took could grab it from there.

> get around the global nature of CSS

That can be done with proper scoping supported naturally by CSS.

Local CSS is still not as bad as moving CSS declarations to JavaScript.

[scott113341]

An additional problem is that even when CSS is properly scoped, you end up with wasted bits over the wire by sending down duplicated declarations. I did some cursory research using cssstats [1] because I was curious how many CSS declarations are unique. Turns out it's about 20-25% for most "big tech" websites.

Gzip helps reduce the impact of this, but Styletron's gzipped CSS is still much (40% or so) smaller than the other CSS-in-JavaScript implementations [2]. In some cases, the cost of switching to using a tool like Styletron might be justified by faster loading times in low-bandwidth markets.

[1] http://cssstats.com

[2] https://ryantsao.com/blog/virtual-css-with-styletron

[matchu]

Bandwidth was the major motivation for building Aphrodite, too: Khan Academy wanted to decrease the number of bytes required for the initial pageload. http://engineering.khanacademy.org/posts/aphrodite-inline-cs...

> We must deliver the absolute minimum amount of CSS necessary by only sending down CSS in use by components in the server-side rendered body. This rules out extracting all the CSS used in all of our components at compilation time, as much of that CSS would not be needed for the initial page load.

Colocating styles with components is a win, but, more importantly, styles-as-JS-objects was the simplest way to get this perf feature out the door.

[kowdermeister]

Faster load times is bit of a stretch. While it's true that up to 40% sounds good, but we are talking about a few kbytes here meanwhile images penalize you much much more on load time. And what do we sacrifice? Mixing concepts that shouldn't be mixed in the first place.

Duplicated styles also compress better with gzip as you said. Do you think stripping a few kbytes is worth turning your whole process upside down?

[rtsao]

You're absolutely right that you can do it with pure CSS. But doing a pure CSS solution usually involves some CSS methodology that you need to apply extremely strictly and consistently, which honestly can be a challenge, especially in large apps. Sometimes it's easier to just throw in a new selector at the end of your stylesheet and "make it work". Without discipline, things can get messy pretty quick.

The point of CSS-in-JS and CSS modules isn't that it's necessary, just that it makes avoiding these sorts of problems much easier.