The cover image was taken from another article, named exactly the sameYou Don't Need CSS-in-JS: Why (and When) I Use Stylesheets Instead by@colbyfayock, however there are not much articles like that (exceptthis one - You Don't Need CSS-in-JS, which uses the same image and, well, the same author 😎), or like this - usuallyeverybody 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 CSSshits 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 theexactly the same way - "hashing" classNames, so they would never conflict.
Implicit dependencies
By which different authors implytechnologies methodologies likeBEM,SMACSS orAtomic CSS, which might help you toto reduce the lack of built-in scoping mechanism.
👉 please go read about these methodologies again. They have nothing with "scope" and "namespacing", only withseparation of conserns, the majority ofCSS-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? WithCSSModules you refer to your styles asstyles.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 forJavaScript. It's faster to fix the problem, that to talk about it.
Even more - usually CSS minification happends on thecss-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 aboutconstants, not dynamic variables.
People useCSS-in-JS to create dynamic styles, and share some variables from JS. LikegridSize orwhiteColor, ormargin-left. They are using dynamic nature if CSS-in-JS to create static styles, which will be never changed in runtime. Thenight mode included. It could no more than a media query - it's more about your code style.
Let's double-check
@mxstbr, creator ofStyles Components once wrote an articleWhy 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, onlymethodologies preventsspecificity wars, as well as helping moving forwardregardless 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 orCSS-in-JS, likestyled-system - it's aSYSTEM, orxstyled - which is also a SYSTEM, orthousers - which is a realstyling STATE MACHINE.
However, CSS-in-JS by itself is usually nothing more thanstyle 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 calledcritical 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)
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.
- LocationKochi
- EducationRajagiri School of Engineering and Technology
- WorkDeveloper at BigBinary
- Joined
This article does make the fact that you don'tneed 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 otheratomic 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 havestyled next 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.
For further actions, you may consider blocking this person and/orreporting abuse
