You dont need CSS-in-JS #1: Why?
Tags: webdev, css
Published: 2020-03-19 10:02:43

---
title: You dont need CSS-in-JS #1: Why?
published: true
description: Let's talk about what you really need.
tags: webdev, css
series: you-dont-need-css-in-js
cover_image: https://thepracticaldev.s3.amazonaws.com/i/80fexbdx36aqhdwj91ai.jpg
---
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](https://www.freecodecamp.org/news/you-dont-need-css-in-js-why-i-use-stylesheets/) by @colbyfayock, however there are not much articles like that (except [this one - You Don't Need CSS-in-JS](https://dev.to/colbyfayock/you-don-t-need-css-in-js-why-i-use-stylesheets-20), 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:

{% link rleija_/5-reasons-to-go-with-css-in-js-for-your-next-application-43m %}

## 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.scss` when you delete `Component.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-JS` is quite good with it. It's easy to share `js` constants.
- `LESS`/`SASS` is 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](https://styled-components.com/) once wrote an article [Why I Write CSS in JavaScript](https://mxstbr.com/thoughts/css-in-js). 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](https://github.com/styled-system/styled-system) - it's a __SYSTEM__, or [xstyled](https://xstyled.dev/) - which is also a SYSTEM, or [thousers](https://github.com/danieldelcore/trousers) - 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
{% link https://dev.to/thekashey/optimising-css-delivery-57eh %}


# 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.