A Brief History of CSS
In the beginning there was HTML. And we added a few inline styles, perhaps a marquee or a little animated GIF, and we saw that it was good.
Reductive, of course, but webpages in their nascent form were often a troublesome concoction with very little of what we beard-stroking developer types might call “separation of concerns”. Put more plainly, things weren’t always particularly organized, with jobs like layout and styling all handled in a multitude of ways, often at cross purposes.
But the world of CSS continued to develop, and our processes matured. Now our HTML was (largely) used only to define what was on our page, not how it looked or where it was positioned. We could separate the code which handled our styling into its own stylesheet and file those away in their own little directory. Neat and sensible.
The years passed, and the tools we had on offer began to grow. We were spoiled as browsers evolved and our CSS became capable of things like rounded corners (imagine that!) and drop shadows. Buttons on web pages became shinier and more, uh, 3D-looking. People started using words like ‘skeuomorphic’. We were in a golden age of styling flexibility, for better and worse.
As if that wasn’t enough, we soon began tricking out the way we wrote CSS in the first place with fancy new variant languages like SASS and LESS. These were in turn compiled with new build tools like Grunt and Gulp (apparently only onomatopoeia are allowed when naming this kind of thing). This 1-2 punch blessed us with all manner of handy functions: nesting our CSS so we could write less of it; defining parts we could re-use so we could write less of it; writing functions that would generate CSS for us and therefore we could write less of it. As you can see, we developers are
a lazy an efficient bunch.
Not only that, but we could now split our CSS into handy little modules to be even more organized. If there is one thing that developers love, it is taking one big file and turning it into ten smaller files.
We had reached a golden age of CSS efficiency and organization. Job done. CSS? Completed it, mate.
CSS in JS
With that little preamble out of the way, here I am writing about moving our CSS back inline again. Heresy!
However, as much as we are able to organise our code that way, the end result is often one, big stylesheet containing everything, or nearly everything, for our entire website or application.
Instead, the advantages of CSS-in-JS come back to our initial idea of separation of concerns. The thought behind this new approach suggests that both the interface and the behavior of component should all be contained within a single file. Following on from that, the scope of all this code remains very specific to its component. To put it another way, if we use CSS-in-JS to make a button blue, there is no risk that anything else on our web page will end up that colour accidentally.
But is it for me?
At present, I am not sure how I feel about all this, although I can understand the advantages in theory, at least. One aspect of this is the rate of change of our industry. I am hardly the first (nor the hundredth) person to point out that sometimes it feels like there is a new technology to learn almost every week. With this landscape comes a certain caution about making changes to tried and tested methods. The flip side to that, however, is that we are frequently offered new opportunities to improve our processes and, by association, our end product.
As with many things I remain on the fence until presented with an opportunity to strike. We won’t be rushing to abandon our tried and tested process, but I’ll be keeping a close eye on this space.