Classical CSS vs CSS in JavaScript

Classical! I think CSS is poorly misunderstand and slighted - when understood and well applied CSS can be a powerful tool or a frustrating after thought.

• Rachel Andrew on Regactoring our perspective of CSS
• Quora post with good remarks

I'm a convert to CSS-in-JS. The developer experience is really great. The cognitive overhead of keeping my component styles in separate files and switching between them was aggravating. It cost time and mental energy to keep track of everything. In the same way using a mouse is slow and distracting compared to keyboard shortcuts, CSS in separate files from JS components is slow and distracting compared to keeping it all together. It's still a separation of concerns, but the concern isn't style-vs-login; it's separation by component.

My bias is that I don't use Javascript much, and I don't use componenty things like React at all.

But I strongly dislike CSS-in-JS, and disagree with anyone who says that it's a good separation of concerns.

I think that the CSS-in-JS movement came built on two trends.

First, the "framework" idea where CSS is used as shims for inline styles, with utility classes such as "large-text" or "padding-right-10" or whatever, and millions of non-semantic wrappers. These break any separation of content and presentation you might want by meaning you have to update your HTML every time you change anything about your appearance.

Second, the rise of node. People jumped aboard node more than previous languages/frameworks because they often already knew a lot of the language from classical Javascript, and because they saw an opportunity to re-make something in a relatively easy manner. Suddenly a million people without an original idea between them could put that they were the "maintainer" (or "creator" if they were being particularly shifty) of a package onto their next job application.

These together mean that the world is unapologetic about crossing style and semantic concerns or about needlessly remaking everything in JS.

When CSS-in-JS came around they didn't stop in their tracks and say, "hold up". It doesn't seem like a bad idea to them.

If I have a widget and I want to place it on a site in a main content area or a sidebar or a footer, I want it to get its styles from the cascade. CSS-in-JS simply can't do this, unless you import a bunch of common styles inside each widget. I've seen that advocated, and you know what? It's reinventing the cascade. Why import common styles in JS when you already have a way of doing it? One that won't break when your script throws an exception or fails to load?

I think, if anything, it should be called Style-in-JS, because it's not CSS. It doesn't use its own stylesheet and it avoids the cascade. Style-in-JS is OK. It's not exactly nice, but who hasn't written a hack somewhere that does more than a display: none toggle when there's no obvious easier way?

It's just, well, if I edit styles in my JS, I'd add a comment saying // @TODO: move these to a stylesheet.
And if I was going to keep CSS tied to JS, I'd at least keep it in a separate file.

Classical CSS. I tried CSS in JavaScript and I didn't like it. I am so use to connecting the HTML, CSS and JS separately.

Embedding CSS in Javascript makes a web app nearly unmaintainable on the long run. You start noticing it when you wonder where the hell that odd margin or background on an element came from, just to find out that it was set by some random script on a random created/mounted event. And what if you want to change the framework used by your frontend? If you keep JS and CSS separate, then it's easy to change the logic without breaking the style. Otherwise, be ready for crying.

A lot of issues in today's web development come from mixing templates, style and frontend logic all together. It took more than a decade to realize that mixing templates and backend code, like PHP or JSP would do, was a bad idea that led to unmaintainable and undebuggable code. It'll probably take the world one more decade to realize that mixing styles, logic and templates is an awfully bad idea for the exact same reasons: logic layer and presentation layer ought to ALWAYS be separate.

I ❤️ CSS-in-JS because it's so easy to use (although I may be biased because I'm very used to it at this point). I use it in all my side projects if I can.

It's not perfect though, and it can cause performance problems depending on what you're trying to render. There are some people at Atlassian who are trying to solve some of these performance issues with compiled-css-in-js so it will be interesting to see where that goes.

Classic css feels like cubersome for me. But it does give me benefit of using css classes anywhere. I'm not into CSS-IN-JS but I just hope that CSS can be as strongly typed stylesheet as Any other languages it would be.

OFF-TOPIC: Still waiting for FLUTTER VS REACT NATIVE Post. That's the most talkative Mobile framework on the web. Well of course, my profile pic says it all.

It's gotta be a split. The entire theme can't be done inside JS components. I love something like Tailwinds in the template and then CSS in js for the components. It's the best way I know to stop a stylesheets' persistent growth.

CSS scoped is a nice shortcut to reducing complications, and it is still CSS in HTML.

In the end, I still prefer CSS in HTML for SEO purposes, perhaps still with Webpack and mini-css-extract-plugin.

CSS in JS seems like just another iteration of how to complicate software development. There are also performance issues and compilation issues. My school of thought is "If it's not broke, don't fix it". CSS is a unique language in and of itself. It has expanded a lot in recent years first with animations and now with vars, additional features to forms, cool pseudo selectors and functions like mathematical calculations on vals. I honestly don't think there is a need to change how I program unless the library or framework I'm using is better served by using CSS in js, such as React (which is built for this).