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

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 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 that was accessible to more designers and visually creative people. Furthermore, it was easy to use and implement.


Fast forward to 2019, and JavaScript is now creeping more into to the CSS space.

Now before you think this is a rant where I hate on JS, it is not. I really like writing 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.

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. 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. Writing CSS well is another story, but honestly, it *is* easy for just about anyone to get started writing CSS.

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

The pros of using CSS with JS includes 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.

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, of which I feel is overkill for its intended use.


I’ve tinkered with CSS-in-JS and postCSS in my foray through the JAMStack, but for my use-cases neither of the concepts have really sold it to me and so I’ve never used any in a production build. In fact it’s been an almost entirely frustrating experience for me that it actually sounds refreshing to go rogue and skip the build process altogether.

Is it really 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?

There’s just something really irritating about having to debug JavaScript errors whilst working on the front-end of a website.

The problem I have with postCSS is the same problem I often have with npm:

  1. 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.
  2. Add to this the fact that you have to plug in all these variables and plugins yourself, essentially, writing an entire config file.
  3. And on top of this, if there is no plugin suitable for your project, you write a plugin to process it the way you want.

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

JavaScript errors are common if you’re relying on plugins, meaining you’d have to debug the plugin error and your zen-mode would potentially be disrupted.

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

The more projects and sites I see on Github, the more I feel like 90% of the build processes are crafted with unnecessary complexity and obfuscation. And for what? Honestly, I’d love to see how a postCSS or CSS-in-JS build is being maintained a year from now.


Here’s an example I tinkered with earlier.

Recently, I have been dabbling with Eleventyone, a static site boilerplate by Phil Hawksworth. It is a pretty good boilerplate to get started using eleventy quickly, and for the most part is easy to understand and use.

I personally modified it for my own needs and planned to use it for some upcoming projects, but honestly it is the build process that has dissuaded me from using it for any real project so far despite how much I tried to pare it down.

One of the first things I did was review how the assets are processed, of which, I was not too satisfied with for my own personal workflow.

The postCSS based workflow is a little something like this:

  1. Navigate to a folder named postcss.
  2. Write your CSS in multiple pure CSS files (like you would with Sass but using the .css extension instead). The caveat of using a css file with postCSS syntax is that you get problems of syntax highlighting and linting by code editors unless you have specific settings and extensions installed. The same caveat goes for using HTML in markdown, CSS in JS, and handlebars in JSON. Mixing languages together results in highlighting and linting problems you have to hack your way around- it’s just the nature of the JAMStack.
  3. Your CSS files are then processed by postCSS, it’s config file living in a separate folder named just css in a parent directory.
  4. PostCSS uses a few plugins to output the compiled CSS to another css folder in the _includes folder, the compiled file is now called main.css.
  5. 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, but 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 customise how the CSS was processed (I simply wanted to change the compiled file name and use some sass mixins.)

const fileName = "styles.css";

module.exports = class {
  async data () {
    const rawFilepath = path.join(__dirname, `../_includes/postcss/${fileName}`);
    return {
      permalink: `css/${fileName}`,
      rawFilepath,
      rawCss: await fs.readFileSync(rawFilepath)
    };
  };

  async render ({ rawCss, rawFilepath }) {
    return await postcss([
      // require('postcss-comment'),
      require('precss'),
      require('postcss-import'),
      require('postcss-mixins'),
      require('postcss-color-mix'),
      require('cssnano')
    ])
    .process(rawCss, { from: rawFilepath })
    .then(result => result.css);
  };
}

This essentially is why I’m never satisfied with the average build process these days. The fact that CSS and JS is so intertwined that to write and maintain the CSS, you also need a fairly good, but mostly assumed gosh darn *excellent* understanding of modern JavaScript to be able to debug things on the fly while you’re in the middle of working on the front-end of the website.


At the end of it all, you have a website that uses CSS. Pure 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.

Maybe in large enterprise situations, I could understand the use of things like postCSS or CSS-in-JS. 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 more people to to work on the web when the majority of build processes wall off the most accessible part of a website- its display.

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.

If it’s just you working on the project, or you’re tinkering for your own personal development, you do you. If you are working in a team though, or even on a project by yourself for a client, maybe 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.