A Unified Styling Language
Mark Dalgleish
4.4K55

This crazy fad of producing CSS through reams of JS might be the most ass-backwards thing I’ve seen emerge from the mad clusterfuck of the front-end development ecosystem.

These tools start from throwing away the benefits of using actual CSS, and then try to cobble together ways of getting them back. It’s retarded.

Notice how there are now lots of different flavours of “CSS in JS” (in the general sense of those three words together)? When everyone and their mother wants to write their own version of X, you know that X is fundamentally flawed in some way.

Astute readers may realize the same applies to Redux too!

The problem you have with CSS is that you don’t use CSS classes properly, and so, you have problems scoping your CSS rules to the elements you want them to apply to.

But that’s not a problem with CSS itself. In other words, every one of these tools is a solution in search of a problem.

They all produce CSS of course, because that’s what browsers understand. Thankfully, browser vendors haven’t gone down this path, yet.

Anyhow. You can write your CSS selectors using combinations of classes. You’ll have a hierarchy of elements, and you’ll have a hierarchy of classes in the selectors.

But the trick is to have several classes apply to one element, for the purposes of scoping your rules.

As a simple example, let’s say form fields look different under a horizontally laid out form than under a vertical one.

So you use a combination of .form and .horizontal to scope the .field.

.form.horizontal .field {

<stuff>

}

Now you have some rules that won’t apply to a .form .field, nor to a .form.vertical .field.

And there is much rejoicing, and you won’t be tempted to get aboard the crazy train.

(That’s right, I can’t get Medium’s code styling to work)

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.