you-dont-need-css-in-js (2 Part Series)
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.
Because it's much better than just CSS, according to the other authors:
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.
By which different authors imply
technologies methodologies like
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.
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 delete
- 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
CSS out of the box doesn’t have a feature to minify code.
As well as for
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.
CSS-in-JSis quite good with it. It's easy to share
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.
CSS-in-JS to create dynamic styles, and share some variables from JS. Like
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.
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.
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.
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...
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".
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.
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
- 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
- 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.
(open source and trusted by devs everywhere ❤️)