[exclipy]

The original argument for CSS from 20 years ago was:

Instead of saying: `<font size="20"><b>Some heading</b></font>` 100 times, CSS proponents would tell you to just write `<h2>Some heading</h2>` 100 times with styles defined separately as `h2 { font-size: 20pt; font-weight: bold; }` so if you need to change it to 22pt, you can make one change instead of 100.

Components give the same benefit. Just write `<Heading>Some Heading</Heading>` 100 times with the definition `function Heading(props) { return <h2 style={{fontSize: 20pt; fontWeight: bold}}>{props.children}</h2>; }`. If you need to update it to 22pt, it's still just one change; not 100.

* replace `style=` syntax with your CSS-in-JS framework of choice for better performance.

[e12e]

Right, but in the example linked from the official docs, the css/style is in the component. So you need to change all your comp, rather than the body font style?

(obviously you can mix and match, it just seems that the official documentation/sentiment is towards self contained components that don't support page/application level theming/styling)

[exclipy]

You're subscribing to the notion that it's good to put all your styles for all components in one file. Since the invention of variables, that is wrong.

Theming is no longer a valid argument for centralized style sheets. If you declare one central set of variables for, eg., colours or fonts, then you can still do "application level theming" (changing those colours/fonts in one place), without having to mash all the styles for every element in the entire app together in one file.

The advantage of using JS variables to represent this is you can easily ask your IDE to "find all references" to that variable. It's much easier for humans than reasoning about CSS inheritance and the cascade.