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!
Well, it’s not quite that simple. As I have mentioned before, JavaScript has become a growing part of our work, and with changing times we have to think about changing approaches. More and more we think about the interfaces we design and build in terms of components rather than pages or views. Our mindset has changed, and this goes hand-in-hand with tools such as SASS which allow us to organize our CSS in terms of components.
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.
But there is another way. For projects which use JavaScript bundled into tidy, discrete components, we now have the option of the ‘CSS in JS’ approach by using libraries such as Styled Components or Emotion.
Now, one initial benefit of this approach is that we are only loading the CSS required for the specific components being loaded on any one page. This is good for performance. However, this aspect is not necessarily unique to CSS-in-JS, as we can achieve the same thing by bundling modules of standard CSS alongside our JavaScript components.
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.
Further to that, it changes the relationship between the JavaScript and the CSS we are writing. Put simply, it can allow a more efficient approach when the appearance of our component – e.g. the opacity of a button – is directly related to its status – e.g. whether it is marked as ‘active’.
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.
If you’d like to find out more about our web development offering, get in touch with the team today.