A rant about the State of CSS in 2019

Published July 3, 2019
.* :☆゚

I love CSS.

If I were to choose something that keeps me coming back to web development, CSS would be it. I love that it is objectively:

  • accessible for newbies and experts alike
  • verbose, easy to understand
  • powerful
  • flexible

Now with that said, I love CSS largely because it is now easier than ever to use and maintain.

I personally love Sass and use it on a daily basis. Some of it’s syntax changed my entire perspective on designing for the web, and I feel like when it entered the scene, it truly empowered not just developers but designers as well to create more interesting and maintainable websites.

CSS has been considered messy and sometimes annoying in it’s quirkyness, and I can relate so hard. I have many memories of being completely stumped over a CSS thing because some of the spec truly is questionable.

However, with the popularity of Sass, for the first time, it made writing CSS a lot more understandable and readable. Concepts like nesting classes and selectors seems completely obvious now, but I feel like the concepts Sass/Less made popular really paved the way for a more maintainable web. Furthermore, it was easy to use and implement.

Now fast forward to 2019, and we have more and more JavaScript creeping in to the CSS space.

Now before you think this is a rant where I hate on JS, it is not. I like JavaScript and love that it has empowered so many people to create things that likely would never have been possible even a few years ago. But, I only like using JavaScript when it is used appropriately and with the right context and finesse. For many use cases, I feel like it is overused and simply unnecessary, as I will explain below.

For many developers, combining CSS and JS together in the build process or front-end is a good thing. The pros include less requests to the browser, less clutter in the code, easier to maintain CSS, a faster paint time etc…I’m sure if you are a developer yourself you’ll understand all the supposed benefits. For me though…well I have issues.

Firstly, I think I can safely say CSS is automatically considered ‘easy’, ‘simple’, ‘ugly’ or perhaps all three by developers. It’s ok, you can admit it, I’ve thought and assumed all these things myself over the years.

“Oh it’s so verbose and easy to understand, surely writing CSS will take far less time and effort than this complex JavaScript app that handles user registrations and multiple states with ease”

Ok I’m vastly exaggerating and assuming a lot …but you get the idea. No matter how simple or easy to understand you think CSS is, it’s obvious to me having worked in the industry for a while now that CSS is not considered particularly hard to write, pick up, or use no matter what people say.

Secondly, with the abundance and reliance of JavaScript in websites/apps today, CSS is now often intertwined with JS through the build process, the idea being that it makes the overall development more “simple” and “maintainable”.

Now if the assumption is that CSS is easy to jump in, read and use (which for the most part, I think it is), why throw JavaScript in the mix and abstract it even more?

In more and more projects and boilerplates I’m seeing (I’ve been dabbling in static site generators a lot the past few months), I realise much of the CSS build process now involves complex JavaScript-based build steps, many of which I feel are over the top and unnecessarily complex.

As a small disclaimer, I want to point out that I see and understand things mainly through the eyes of a designer. But a designer that codes often. And this designer/developer is frustrated at fumbling around with messy build processes and debugging multitudes of JS errors, simply to output pure CSS code.

My experiences with CSS-in-JS is limited I admit, but I have had a few postCSS issues in recent times and it really has made me question if it’s worth the time investment of abstracting CSS so far from what it actually is, to the point where it actually takes more time to debug overall than it does to actually construct it.

I suppose as I was using postCSS, I could see the benefits. Some of them anyway. Until the errors started popping up, then I had to stop all the CSS and debug the JS, which is so not something I want to be doing when I’m working on the front-end of a website.

The problem I have with postCSS is the same problem I often have with npm. There are multiple plugins which seem to do the same thing, and you have to cherry pick and research, look at github stars etc. to gauge whether or not it is worth using in your own project.

Add to this the fact that you have to plug in all these variables and plugins yourself, essentially, writing an entire config file.

And on top of this, if there is no plugin suitable for your project, you can always write your own plugin to process your CSS.

Things like minifying, nesting, using mixins, are third party plugins, all with different code standards, that you have to include in the config yourself.

And if you end up with errors, well you have to now work with the JavaScript, not CSS.

Oh and syntax highlighting? It’s not as simple as installing a VS Code extension.

The whole process for writing and maintaining CSS can be so complex and confusing to an outsider who has no initial knowledge of the code, that sometimes it it seems like it would be easier to hand code it all rather than rely on flaky plugins to do the heavy lifting for you.

In my foray with static site generators and boilerplates, oftentimes the build process is crafted with such complexity that it essentially shuts out people with minimal JavaScript knowledge.

Confused? Defensive? Let me give you an example.

Recently, I have been dabbling with Eleventyone, a static site boilerplate by Phil Hawksworth. It is a very well made boilerplate and for the most part, easy to understand and use. I personally modified it for my own needs and plan to use it for some upcoming projects soon, and am very grateful to him for providing it to the public.

One of the first things I did was review the CSS build process, of which, I was not happy with for my own personal needs.

  1. The process involved navigating to a postcss folder, writing CSS in multiple pure CSS files (like you would with Sass but using the .css extension instead) but with postCSS syntax, which results in problems of syntax highlighting and linting by code editors unless you have specific settings and extensions installed.
  2. This CSS is then processed by postCSS, it’s config file living in a separate folder named just css in a parent directory.
  3. PostCSS uses a few plugins to output the compiled CSS to another css folder in the _includes folder, the file is now called main.css.
  4. This file is processed again by Eleventy and output to the site’s public folder where it is now called styles.css.

As a third party using this project, this process felt very clunky, cluttered, confusing, and visually unappealing.

If I got any part of that build process wrong, please feel free to correct me. Working out the entire build process was downright confusing for me regardless, and if anything my difficulty in explaining how it all works is a testament to how confusing and convoluted it is.

Add to this the fact that I had to wrangle the following code to modify how the CSS was processed (I just wanted to change the compiled file name and use some sass mixins…that didn’t work out):

 1const fileName = "styles.css";
 3module.exports = class {
 4  async data () {
 5    const rawFilepath = path.join(__dirname, `../_includes/postcss/${fileName}`);
 6    return {
 7      permalink: `css/${fileName}`,
 8      rawFilepath,
 9      rawCss: await fs.readFileSync(rawFilepath)
10    };
11  };
13  async render ({ rawCss, rawFilepath }) {
14    return await postcss([
15      // require('postcss-comment'),
16      require('precss'),
17      require('postcss-import'),
18      require('postcss-mixins'),
19      require('postcss-color-mix'),
20      require('cssnano')
21    ])
22    .process(rawCss, { from: rawFilepath })
23    .then(result => result.css);
24  };

This essentially is what I have a problem with. The fact that CSS and JS is so intertwined that to write and maintain CSS, you also need a fairly good understanding of JavaScript and need to be able to debug things on the fly, possibly while you’re in the middle of working on the front-end of the website.

At the end of the day, CSS is CSS. The argument that postCSS lets you use future CSS is flawed in my eyes, because although it will output CSS with current day specs, you still need the build process to work properly in order for it to be fully processed. This means relying on third party plugins written by various people using different code standards. This is why I still love using Sass- it is easier to turn on syntax highlighting and as far as maintainability goes, is in my opinion very reliable and the easiest to use.

Maybe in large enterprise situations, I could understand the popularity of things like postCSS. For static blogs and personal sites? Not so much.

CSS doesn’t need JSON files, config files, or obtuse plugins for it to be written well. There are many parts of CSS that could be made better, but it’s future is clearly intended for a more flexible and creative web. Just look at the CSS grid spec. Or the upcoming text-underline spec. The web needs designers to be working on these things in the future. But in the current state of CSS, it is much harder for a designer to work on the web due to convoluted, over the top build processes.

In my designer-based opinion, complicating the CSS build process with an abundance of JavaScript actually hinders the creative process for people like me, who just want to spend more time crafting the display layer of the site rather than the underlying back end.

This rant is not because I don’t like writing JavaScript. When things like postCSS is working flawlessly, it’s all great. When things break or when you need to customise a config file though, I get frustrated, and in all likelihood it will take me more time to debug the JS than it will to write the actual CSS.

Developers are always in the pursuit of keeping things simple. But in the attempt to make things simple, I feel like steps made to achieve that often has the opposite effect of making things that much harder to understand and use.

Fair enough if you are coding for your own personal development. If it’s just you working on the project, you do you. If you are working in a team though, or even on a project by yourself for a client, please think about how easy it will be for other devs to jump in at any point in time. Not just in the next few months, but the next few years. I think this pragmatism is a big part of what separates a good developer from an excellent one, and I really truly appreciate coming across this thoughtfulness when I work with old code written by someone who has clearly kept this in mind.