Ryosuke

Designer / Developer / Influencer

Sep 5, 2018

CSS in JS is great for design systems or complex applications.

It allows you to bring in any component without ever worrying about style conflicts due to CSS and it's global nature.

I can use a button from one library and a button from a completely different author and never worry about CSS overlaps (if one or both uses CSS in JS).

Great for complex apps that have a lot of components and the team struggles to keep CSS class names in order (BEM and OOCSS only go so far).

Also great for designers looking to quickly prototype or iterate components using complex CSS without setting up pre/post-processors or build systems for CSS or supersets of it. You get all the benefits of SASS with CSS in JS, without the need to re-build on code change (sorta, if you don't count your app hot-reloading 😅).

Pros

CSS in isolation. No more writing a .button class and having global conflicts (and forced to resolve them with specificity or dreaded !important tags).
Less dead code. It's easy to have CSS get lost in generic or even component-specific stylesheets. It makes CSS easier to delete when it's tied closer to the actual component.
Vendor prefixing. No need to stress over -moz this or -webkit that.
CSS manipulation through JS. Either using constants, values from the state, etc -- you can make your CSS more dynamic and responsive to your code.
Smaller CSS bundle per page. You only load the CSS you need, instead of excessive stylesheets, normalizers, responsiveness, etc.

Cons

Abstraction of CSS (depending on library - StyledComponents and EmotionJS do a good job of writing pure CSS)
Extra DOM to load with embedded styles + longer class names * Longer load time on each component. It might be minuscule for some libs, but it stacks up regardless.
No caching of stylesheets, only page caching with embedded styles
Breaks DRY in production since styles are isolated by page/component, meaning each page will deliver same CSS over and over again (SSR apps in particular, SPAs prob won't feel this effect as hard).

Myth

More dependencies. CSS, SASS, LESS, etc - all often require dependencies in modern applications. Whether it's a Webpack or Gulp plugin, you probably already have dependencies for CSS. Using CSS in JS libraries only imports one dependency. I haven't compared bundle sizes, but JSS is pretty small under the hood.
Learning curve. There's really nothing extra to learn if you use the right library (like SC or Emotion). It's honestly even easier than ordinary CSS, since you element scope -- making writing new CSS less of an anxiety (worrying about breaking styles globally on another page/element).

Great for complex apps that have a lot of components and the team struggles to keep CSS class names in order (BEM and OOCSS only go so far).

If you have enough CSS for this to even be an issue, you're using too much CSS; but that's the case most of the time IMHO where I see people using half a megabyte per PAGE where I'd never even have 48k for an entire SITE.

No more writing a .button class

You know, I always cringe when people write a class '.button' and then put it on an anchor. It's not a button tag, it's an anchor. More useful would be to say what the anchor DOES or where it GOES... or hook it off the parent's descriptive class that should be created the same way.

This goes hand in hand with how mentally enfeebled I consider halfwitted class use like w3-red, text-center, box-shadow, etc, etc to be. You want to use classes like that go back to the presentational 1990's HTML 3.2 or 4 Tranny; the latter meaning "in transition from 1997 to 1998 development practices"... As I've said many times it seems like the people getting wood for this type of methodology really miss their FONT / CENTER tags, ALIGN / BORDER / BGCOLOR / FACE attributes, and tables for layout -- completely missing the POINT of HTML and what 4 Strict was trying to drag us towards.

On top of that, it's as confusing to call an anchor .button as it is people using .active on a menu... don't confuse the namespace. Or the use of needlessly vague filenames like 'style.css' -- instead of something useful like 'screen.css' so you can set media="screen"

Of course with the folks who use this stuff NEVER using media attributes or flipping the bird at them using media="all" therefor derping their screen layout to everything... well... /FAIL/ again. You see STYLE or a stylesheet LINK lacking a MEDIA attribute, it's another indicator the developer is unqualified to write HTML and ignorant of the most basic of concepts!

Less dead code

This one's often funny as I'm accused of having 'dead code' by people a lot -- what they fail to realize is that 1) I'm still using 1/10th the code or less than how they'd do it, and 2) The "dead code" in question is usually just me pre-caching the appearance of sub-pages. Hence why once you visit one page of my sites all the sub-pages load in a eyelash blink -- since typically all they have to load is ~8 to 24k of markup (depending on the content) and any content images. (Since I keep template images separate from the markup or the content images)

But that's the con you listed:

No caching of stylesheets,

Which should IMHO ALWAYS be a deal-breaker.

Though it's funny you list this as a pro:

CSS manipulation through JS

Since it just begs for the site to go bits-up face-down when scripting is blocked. Depending on WHAT breaks when scripting isn't present that could land you in hot water on the accessibility front and is why I wouldn't list that as an advantage to using it. As I said on another reply the only times I could see that being useful is for realtime calculated values, in which case you'd only be setting one or two values, at which point just use Element.style!

More dependencies. CSS, SASS, LESS, etc - all often require dependencies in modern applications. Whether it's a Webpack or Gulp plugin, you probably already have dependencies for CSS.

Assuming you meant SCSS as that first one, that's ALL crap I don't use and tell other people not to use because they are more work, less versatile, HARDER to maintain or debug. It's all bloated crap that makes people work harder, not smarter.

To the point the fans of that stuff often come across as drooling fools akin to those who believe quacks like Oz, Paltrow, or that dirtbag calling himself an avocado. The claims and behaviors are THAT delusional and out of touch with reality; again much like religious fundamentalists and cultists.

Smaller CSS bundle per page

Then why is it EVERY single page I've ever seen built with any of this nonsense uses ten times the markup AND two to twenty times the CSS needed to do the job?

That's REALLY where the disconnect happens on this in my head, and is the biggest LIE told about any of this trash. That's the part that makes all of this come across as those using it having drunk too deeply of the Jonestown flavor-aid.

But again, my freelance work nowadays consists almost entirely of going into the messes made by this type of garbage and ripping it out to make websites faster and meet accessibility norms. It's getting frustrating for myself AND clients to keep having to throw months or even years of work to start over from scratch JUST because this type of methodology is so -- not to overuse the words -- ignorant and incompetent!

Search Hashnode

Pros

Cons

Myth