CSS Sucks

I recently watched a short talk about styling in JavaScript which began in the way same way that so many discussions about this new hotness do, by proclaiming “CSS Sucks”. These discussions generally go on to tell us how broken CSS is, often providing us with a list of all the shortcomings of CSS; Global scope, the cascade, specificity, inheritance basically a quick summary of CSS’s fundamental design. They tell us “CSS was made for documents not web apps”. We’re then told how writing our CSS in JS will save us.

CSS-in-JS, Styled Components and similar tools — I get it. I understand the argument that seems to be winning the hearts and minds of so many. Sorry but I’m not sold. Like I’ve said I get it, I honestly can see that appeal of these tools. Kudos to the super, super clever people working on these tools, its truly impressive stuff but I wonder if they’re solving the right problems.

The problems

I’ve worked on websites of all shapes and sizes. Corporate websites during my time at Forepoint, a 30,000 lines of Sass beast at the BBC and now an incredibly complex Javascript application at Spotify and I struggle to see what these JS styling solutions would bring to these projects. I have not experienced problems managing the cascade, with the global nature of CSS or with specificity.

I’m not alone here, there are many well known, big web projects which use plain old CSS and have not experienced pain to the extent they feel the need to abandon this fundamental ingredient of the web development stack in favour of a tool which essentially recreates the functionality of CSS just not as well.

It is entirely possible to solve all of the problems using good old CSS. I’ve detailed before how we achieved this at BBC Sport. The tools exist in CSS to solve these problems already:

• Struggling with specificity? Adopt a methodology like ITCSS to tame specificity
• Worried about the global scope? Use a naming convention like BEM or SUIT CSS and think about how the styles you’re writing will effect the wider project
• Got leaky styles? Wrestling with encapsulation? Write better selectors, apply the the single responsibility principle
• Battling with the Cascade? Adopt a clearly defined set of principle you follow when writing CSS

For me these tools don’t solve anything that can’t already be achieved with a solid CSS architecture. So I wonder what is problem are these JS based tools are really trying to solve?

The real problem?

Harry Roberts recently described these JS tools as:

A superficial patch over a larger problem.

That problem being developers don’t know CSS, and nor do they want to learn it.

Whilst I don’t for a minute think this is true for every developer promoting the use of these tools, in my experience I see lots of developers advocating using such tools in order to forgo the need to learn and understand how to work with CSS in a ways which eliminates many of the common challenges people have with CSS.

I find this attitude really interesting. It reminds me of a question Adam Bulmer asked a while back:

Why is it that CSS is not treated as a first class citizen in projects?

I’ve spent the last 4 years working with JS developers everyday (they often say JS words that I don’t understand). These are super smart people who are fantastically proud of the JS code they write. They would not hesitate for a second to call out some sloppy code in a pull request or suggest a better way of solving a problem with some fancy technique. But this passion is sometimes lost when it comes to CSS.

We end up in a place where “if it works why does it matter”. As someone who has made a career out of writing CSS and advocating working with CSS in certain ways this can be really frustrating to see.

I am currently working in a codebase where CSS from different parts of the application is completely sandboxed (unfortunately by iFrames and not one of these shinny tools — thats for another story). Whilst this might sounds like some sort of utopia, everything being nicely sandboxed actually allows people to get away with doing some down right nasty things in their CSS and not have to worry about effecting other parts of the application.

We have actually created an environment where developers don’t have to care about their CSS, where they don’t have to think about the consequences of the code they write. I can tell you this is really not a nice place to be.

Maybe instead of writing CSS in JS we just need to write CSS with the same amount of passion and care we have when we write JS.

Not really a conclusion

Do I think these tools are inherently bad? Not at all.

Would I tell people they shouldn’t be using them? No at all. I solidly believe that teams should use the right tools to solve their problems.

Would I use these tools? I don’t think so, for me they don’t provide me anything I don’t already I have.

When talking about CSS and different tools I always advocate learning more about how CSS works over learning any specific tool be that LESS, Sass. I guess this could apply to CSS-in-JS tools as well.