The point of CSS in JS is to tackle the issue of component based design in a world where applications are built across several platforms with the same pieces. I can have a single stylesheet with all my styles, but I'll be serving CSS I'm not using. Or I can bundle it into modules based on routes or components, but I still have to handle how I'd like to handle this process, either through something like Gulp or Webpack.

The CSS classes you pointed out get minified, it's actually more efficient (less physical code to serve), and with source maps we can review the unmodified source on the fly (or just view the source, you know, in the repo).

The issue with your example is how overtly simplified it is. What happens when my button CSS ("Get more space..") duplicates across other components? Do I add a .button class to the link? Then do I including the button.css in the root component? How do I handle variants based on the component? Are the stored locally in a css file based on the component? What if the changes are atomic, like slight size changes? Wouldn't it be easier to add a style to the button base class that allows modification using a .big or .small modifier? Is this not the same logic behind adding a .text-center global class -- but more efficient? This would result in an element with a couple scrambled style names like you mentioned, and a smaller overall CSS footprint in exchange for extra text to load (especially if we only load CSS we use).

And that's just the button. The h2 element is probably similar and requires a .header type spec to apply styling. Because the h2 in this component might be a header we use in content areas, but it'll differ from the h2 we use in navigational components. Styles based on DOM elements can only go so far, and they're often not specific enough to merit placing in the relative CSS of the sidebar say (.sidebar h2). And they're not global enough to merit bloating our app's CSS across all routes. So where do they go? A general h2.css file with all the variants?

But hey, you're part of the camp that doesn't have to worry about it because of your workflow. It's cool, different keystrokes for different folks. I'm in a camp that struggles with this kind of issue because of our architecture (one of the few exchanges we take for cool stuff like faster JS at scale 😉).

I was hoping to pick the brain of someone with this issue, and see how they tackle the issue, because as you can see from the first paragraph or so, there are lots of ways to slice this pie -- if you participate in the party.

Do I add a .button class to the link?

...you add the selector to the stylesheet in the so called "DRY" style, aka using CSS how it was designed to be used.

but I'll be serving CSS I'm not using

Or you could be pre-caching appearance of subpages you haven't even loaded yet.

But then 90%+ of websites and applications have ZERO legitimate excuse to have more than 48k of CSS apart from -- again -- developer ignorance and incompetence...

But sure, adding more elements to the DOM, more classes to the DOM, the code to do all that, failing to leverage semantics to keep the code tight and presentation where it huffing belongs, is somehow magically going to be faster, easier, or "more productive".

It's the same lies all these "frameworks" peddle that amounts to nothing more than a failure to even grasp what HTML is, what CSS is for, or how any of this stuff is even supposed to work.

See how these scripting twaddles will wrap a paragraph around the obvious section heading, a second level heading around something that is clearly NOT the section heading, "small" around something not being de-emphasized, slopping SVG into the markup where it's not cached across loads of the same or similar pages, and all the other "HTML? That's not a real programming language" BULLSHIT that results in these bloated halfwitted train-wreck laundry list of how NOT to use markup.

Likely from the same lack of knowledge that leads to people slopping "DIV for nothing" around UL or FORM because they' don't even realize those are perfectly good block level containers, using classes like "w3-red", "text-center", or "box-shadow" because they missed the entire reasoning for the tags and attributes deprecated in HTML 4 Strict, and are so unaware of the meanings of HTML tags they actually bought the LIE that the purpose of H1..H6 is to declare fonts in different weights and sizes.

They aren't.

I'll never grasp how creating two to ten times the HTML needed to do the job, or vomiting up a slew of JavaScript to make an even larger DOM with more rules that are slower to render is somehow easier, simpler, or better than just putting your damned presentation where it belongs -- where it can be cached and even pre-cached -- IN THE STYLESHEET!

The BEST it accomplishes is moving the same amount of code out of the stylesheet and into the markup/scripting. At WORST it's many times MORE code AND pisses on the entire reason HTML is separate from CSS and everything HTML 4 Strict was trying to get us to stop doing! As I've said repeatedly about front-end frameworks for over a decade, if you're going to do things that way you might as well go back to using tables for layout, FONT and CENTER tags, and outdated outmoded dumbass attributes like size, bgcolor, align, border, etc, etc, etc... That is CLEARLY the mindset people working with HTML and CSS in this manner miss and so desperately want back! Hello bleeding edge of 1997 style markup methodologies! It is for all intents and purposes undoing twenty years of progress.

It's as scatterbrained a bunch of nonsense as this BS being thrown around about moving style out of your stylesheet into the markup to "speed up rendering". It doesn't, and it defeats the purpose of having CSS.

Doesn't make a lick of sense ESPECIALLY when the result ignores the structural rules of HTML and tells users with accessibility needs to go f* themselves!

Though admittedly if you're using web technologies to build crapplets, you've already told such users where to stick it.

OH, and one final selling point, keeping it in the CSS means I can reskin the entire damned thing top to bottom WITHOUT screwing with the markup or the logic generating the markup if I've used sensible placement of semantically neutral containers (DIV and SPAN) with proper semantics. That's ANOTHER of the reasons separation of presentation from content EXISTS!