Today I came across PurgeCSS: a tool that allows you to rid your website of unused stylesheet rules. It seems to be very useful if you’re knee-deep in external CSS dependencies, brought in by the various frameworks and plugins used in websites these days. But preferably you don’t need a tool like this at all. This need is typical of the way modern web development is often conducted. You’re slapdash gluing a bunch of tools and libraries together. Mix it with your CSS framework of choice, say Bootstrap or Tailwind and after a bit of development you end up with a big ball of stylesheets, often 100kB or more. And that is when you reach for CSS processors like Less, minifiers and, yeah, PurgeCSS.
CSS was a godsend when I first started using it in the early noughties. Before CSS I would design web pages by using tables, cutting up a design document into small bits and pieces and carefully fitting them inside the table’s cells and rows. Having CSS and a fixed idea on the size of people’s monitors allowed me to move much quicker. I assumed a maximum screen width of 980 pixels and I just flew, easily recreating pretty much any Photoshop design that was thrown at me.
Unfortunately, or fortunately perhaps, the web grew and so did the amount of devices and screen sizes I had to support. At the advent of mobile browsers I could go by with simply making a wholly separate website running under a “m.” subdomain, and fitting everything inside a much smaller 320 pixels box. This approach was of course not durable at all, since mobile devices started getting higher and higher resolutions. That’s where the new feature of CSS media queries came in handy. It allowed me to have one single “responsive” web design that fitted any browser and things were well for a while.
The effect of all the extra dependencies was also that load-times of web pages started to go up. Not immediately noticeable on broadband connections, but surely a problem when using your smartphone or in other places with lesser connection speeds. This caused the need for minifiers. I needed to reduce the amount of web requests done for a page and this meant fusing all the CSS files into one big file and minimizing it, making it impossible to read for viewers, but much nicer to get across a network.
On another level web developers started using CSS-preprocessors like Less, Sass and Stylus. This allowed for easier development, adding variables and a better separation of design parts. What used to be an activity of simply adding your own styling sauce to a web page, evolved into a very complex declarative programming of some sort.
The problem with the grown complexity is that CSS wasn’t originally designed for it. I don’t blame the designers or the web browser vendors, since they simply adapted it to the quickly changing times, but CSS has grown to be a very complex language. I wouldn’t like to think how it would be to be a junior frontend developer staring at the W3 specifications describing the positioning rules, flexible box layouts, transforms..etc. I can only imagine this to be a daunting, almost impossible task if you haven’t lived through the changes one by one.
The complexity of CSS lies in its originally simple design. It allows
you to make selections of HTML elements and states to which certain
styling rules apply. You can append to earlier rules or override them.
The way in which this works and which rules take precedence is defined
in the cascading order. This cascade starts with browser defaults,
appended by user browser settings and moves up all the way to the mighty
hammer of !important, overriding most things in its path. The problem
with this cascade and the way this works is that it’s pretty hard to
keep all the rulesets in your head. Frankly, with most modern websites,
this is utterly impossible and you have to resort to debugger-driven
development. Using the “inspect element” tool of your web browser you
can figure out which rules apply to which element and you can try to
find out how you could add your own modifications.
For a software developer this practice would be unacceptable. Code needs to be understandable to a large extent. You have to have a pretty good idea about the effects of your work, otherwise it would drive you mad.
As I see it tools like PurgeCSS are a kind of admission of defeat.
There’s so much CSS floating around in our websites that we don’t even
know which rules apply anymore. Most of it is probably brought in by the
handy libraries we used and there’s no way of understanding their
specific construction. I really understand why you would reach for such
a tool and I have certainly wanted to use it in the past. Shocked by the
large amount of CSS used by a website and the poor scores on PageSpeed
Insights any sane person would try to alleviate this.
However, there’s also another way. You could scratch the need for external CSS bloat altogether if you simply refuse to use those and start writing your own code again. The development of CSS hasn’t stopped and in recent years has amassed features that were previously either a fools-errand to implement yourself, or cried out for libraries like Bootstrap. Things like grids, flexible layouts, parallax effects, animations, you name it. Pretty much all of those are supported in CSS3 and you don’t have to write hundreds of lines to get them into your website. I feel that thanks to the quick-evolving nature of web technology we can get all the design niceties our clients desire without ending up with big balls of minified glued stylesheets. That’s exactly the kind of approach I’m going for these days.
One of the many plus sides of being a freelance web programmer is that I often have a large amount of freedom picking the tools and languages I want. I’m usually hired to make most tech decisions myself, not having to fit into the steady drum beat of prescribed systems, frameworks and dodging stimulating Scrum sessions with colleagues. Whenever I can I like to use this freedom to handwrite the CSS for websites I’m working and this is actually kind of fun.
Calling my own stylesheet shots gives me a very nice and orderly feeling. I can get the design just right without first having to go rounds fighting the assumptions of a big framework. I can also keep the complexity in check, making sure that I actually understand what the CSS is doing and where I can find all the bits I need. Sure, cross-browser compatibility can be a pain, especially when everything has to show up nicely in Internet Explorer, but it’s much easier to fix the problems you come across when you actually own the problems.
I like to use semantic HTML tags and pair those with clear sectioning in my CSS file. Combined with all the nifty tricks you can pull you can often reach your goals in much less lines of code. Bootstrap was nice to have around when building responsive grids yourself was like pulling teeth, but when flying solo these days, you don’t really need it anymore.
So next time you’re building a website put on your favorite trainers and leave the marching bands of external CSS libraries on the side of the road and you’ll find it a much nicer journey.