CSS in JS is like replacing a broken screwdriver with your favorite hammer.

There’s a ton of interest these days in ‘CSS in JS’. The premise is simple: CSS operates in a global namespace, which can result in undesirable side effects, spaghetti code, and extremely difficult to maintain codebases. JavaScript used to do this, and we fixed it by encapsulating everything in modules and using tools like webpack to stitch everything together. And hey look, our JavaScript tools can handle CSS too, why don’t we move all of our CSS into JavaScript and encapsulate everything by module!

Thank you for reading this post, don't forget to subscribe!

There is a real problem here to be solved — it is entirely possible to create terrible, unmaintainable, disastrous CSS. In fact, it’s extremely common to do so! And don’t get me wrong, I love JavaScript… but as a solution to this problem, CSS in JS is like replacing a broken screwdriver with your favorite hammer. Sure, you’ll get the screw further into the wall, but you also destroy all of the unique and valuable problems that had you using a screw instead of a nail in the first place!

Key differences between CSS and JavaScript

Let’s take a look at some of the key attributes that differ between the problems CSS is solving and what JavaScript is solving.

Structural/Behavioral Vs Graphical

One of the common arguments for “CSS in JS” is that “we thought separation of concerns was important, but look at JSX!”. The argument uses this example (which is itself still quite controversial) to argue that clearly separation of concerns is wrong and adding CSS to JS will also improve productivity.

This argument neglects the difference between structural/behavioral properties and graphical properties. Separation of concerns is valuable when the concerns are in fact separate, letting you reason independently about the two pieces. The reason JSX provides an improvement in productivity is that structure and behavior are tightly linked — a large amount of JavaScript logic has to do with manipulating HTML structure, so separating the two creates more cognitive overhead, not less.

Contrast this to graphical properties, which are a very large percentage of what is being manipulated by CSS. Rather than being tightly linked to structure, these are very loosely coupled — this is why one can often wireframe an entire application out before styling it! Moving your CSS into your logic introduces unnecessary coupling, leading to more cognitive overhead not less.

Read Full Article

Leave a Reply

Your email address will not be published. Required fields are marked *