The cover image was taken from another article, named exactly the same You Don't Need CSS-in-JS: Why (and When) I Use Stylesheets Instead by @colbyfayock , however there are not much articles like that (except this one - You Don't Need CSS-in-JS, which uses the same image and, well, the same author π), or like this - usually everybody praises CSS-in-JS.
Why CSS-in-JS is so COOL?!
Because it's much better than just CSS, according to the other authors:
Global namespace
Like CSS shits into the global namespace, while CSS-in-JS provides you an "encapsulation" plus "isolation.
π use CSS Modules, they are providing the same level of the thing above, and in the exactly the same way - "hashing" classNames, so they would never conflict.
Implicit dependencies
By which different authors imply technologies methodologies like BEM, SMACSS or Atomic CSS, which might help you to to reduce the lack of built-in scoping mechanism.
π please go read about these methodologies again. They have nothing with "scope" and "namespacing", only with separation of conserns, the majority of CSS-in-JS believers truly understand.
Dead code elimination
Like in CSS-in-JS you can have your styles next to your component, and delete them as you delete your component. For example. It might also be just about styles no longer in use.
Is it true? With CSSModules you refer to your styles as styles.someClass, making the fact of usage explicit, and it should be:
- not a problem to delete
Component.scsswhen you deleteComponent.js - not a problem to track which styles are used, and which are not. That's a linting/IDE problem, not something bound to the technology itself.
π that's not a problem of technology. That's problem of your code style
Minification
CSS out of the box doesnβt have a feature to minify code.
As well as for JavaScript. It's faster to fix the problem, that to talk about it.
Even more - usually CSS minification happends on the css-chunk level, which may contain many .css files, which may contain styles for many components. Read - it WAY MORE EFFICIENT.
Sharing constants
-
CSS-in-JSis quite good with it. It's easy to sharejsconstants. -
LESS/SASSis not worse - it's easy to share constants from CSS->to->JS, and back using webpack loaders.
π ... and yes - usually everyone is talking about constants, not dynamic variables.
People use CSS-in-JS to create dynamic styles, and share some variables from JS. Like gridSize or whiteColor, or margin-left. They are using dynamic nature if CSS-in-JS to create static styles, which will be never changed in runtime. The night mode included. It could no more than a media query - it's more about your code style.
Let's double-check
@mxstbr , creator of Styles Components once wrote an article Why I Write CSS in JavaScript. So Why?
CSS-in-JS boosts my confidence
I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too.
π CSSModules. Full Stop.
keeps our codebase clean and lets us move quicker
With CSS-in-JS, we automatically sidestep common CSS frustrations such as class name collisions and specificity wars...regardless of experience levels.
π No, only methodologies prevents specificity wars, as well as helping moving forward regardless of experience levels.
C'mon - it's possible to create terrible things with CSS, and CSS-in-JS as well. Nothing stops you. That's not something CSS-in-JS could you give - that's you.
Keeps CSS small
Regarding performance, CSS-in-JS libraries keep track of the components I use on a page and only inject their styles into the DOM.
π That "tracking" costs WAY more that extra work browser could perform working with a bit larget CSS tables.
Just follow the best practices, which usually sounds like - don't use nested selectors, as long as browser matches them from left to right, so they might greatly slowdown CSS engine...
Pit of success
CSS-in-JS combines all these benefits into one handy package and enforces them. It guides me to the pit of success: doing the right thing is easy, and doing the wrong thing is hard (or even impossible).
π That's not truth, in the moment of "right thing", and especially in the moment of "even impossible". CSS-in-JS is actually causing more chaos than helping making things "right".
There are "better" versions or CSS-in-JS, like styled-system - it's a SYSTEM, or xstyled - which is also a SYSTEM, or thousers - which is a real styling STATE MACHINE.
However, CSS-in-JS by itself is usually nothing more than style delivery system. It doesn't give you anything special. It's up to you how to use it.
Performance
While my .js bundles are slightly heavier, my users download the smallest possible CSS payload and avoid extra network requests for .css files.
This leads to a marginally slower time to interactive, but a much quicker first meaningful paint! ππ¨
CSS-in-JS send only the critical CSS to the user for a rapid first paint. Which is called critical css extraction and not a feature of CSS-in-JS
Recap: CSS in JS benefits
- Generates minimum CSS requires, which is not required.
- Good runtime performance, which is way worse than with a plain CSS-in-CSS
- Supports dynamic styling, which you might not need
- Easy to pre-render important CSS, which also possible with CSS-in-CSS
- Letting to extract all CSS to CSS, if you want
Recap: CSS in CSS benefits
- Generates big style chunks, which is easy to optimize in bulk.
- It's way faster to load and parse CSS files, than JS files
- Unbound caching for JS and CSS, leading to a better user experience.
- Letting you embed CSS in JS, if you want.
So... honestly - there is no GOOD reason to use CSS-in-JS. Probably you need something else. Something more (like a "system"), or something less(like just styles). Usually less.
Top comments (3)
This article does make the fact that you don't need to use either of the techniques for good code. We have been writing CSS-in-JS for some time now and I have seen poorly written code, so I have to agree doing the right thing is a bit outdated.
But the real reason I have kept writing CSS-in-JS is because I get to keep the styles in the same file as my components. Styles are an integral part of these components and the fact that I can just see the styles that decorate my elements right then and there. Doesn't this put you at disadvantage because you are not seeing the styles adorned by the parent components? Yes, this is true, but that's also the point of creating reusable components.
Can we do this without using CSS-in-JS today? Yes, it called tailwind CSS. But they are not comparable techniques to start with.
Yeah, it's better not to talk about Tailwind, and any other atomic CSS, as long as they are making CSS-in-JS, as well as CSS-in-CSS somehow not important. It's all CSS-in-HTML, I mean your markup.
Anyway - many CSS-in-JS users have
stylednext to "real" components, as well as many have them separated. Nowadays in almost any editor you might separate your view vertically or horizontally and have styles defined in.csseven closer. So this moment is nothing more than a personal preference and thus don't count.I'm sensing just a little bit of bias in this post. It's a bit unfair to add negative remarks to recap of the CSS in JS benefits while adding positive remarks to the CSS in CSS recap.
I agree with the point Agney made. In a lot of cases, the style of a component is very much linked with it, so having the style clearly presented in the same file as the component js is beneficial.