Opto/abs

The State of CSS in 2021

By James Graham · 2021-02-22

If you’ve written CSS for any length of time, you recognize that being able to “write CSS” in the modern tech ecosystem means much more than simply understanding and regurgitating the syntax. Developers today are increasingly expected to have a rich understanding of the dynamic ecosystem that is poised to take CSS from a somewhat boring and clunky necessity, to a truly transformative source of competitive edge. A lot has changed in the world of CSS lately so without further ado, let’s get up to speed…

Pre/post-processors

More and more codebases are beginning to utilize some sort of pre-processor when writing CSS to make the development experience more intuitive and less repetitive (more DRY). Gone are the days of monolithic, unmaintainable stylesheets draining development resources; supersets of CSS3 such as SCSS (and it’s ancestor “SaSS” or “indented syntax”) have revolutionized the way CSS is written with a host of features not currently available in the CSS main spec. Put simply, they give you access to tomorrow’s CSS, today. Here are a few noteworthy pieces of functionality:

$Variables & Functions()

By allowing developers access to variables when writing stylesheets, it is possible to create central sources of truth that lend themselves naturally to theming and other global config required for a given design system. We can now extract our color palettes, typography preferences, spacing defaults and more for rapid vibe changes on-the-fly! But wait, if we have variables…..do we have….functions? Why yes we do.

Functions in CSS work much the way they do in JavaScript, or any other object-oriented programming language. Why do they matter? Well, modern web development requires responsive design which….isn’t easy. Consumers are increasingly consuming content on their mobile devices which means mobile-first design that must account for layout shift and screen size compatibility is a necessity. Creating designs that work well across various screen sizes presents lots of implementation challenges that are solved by allowing developers to use mathematical calculations in SCSS. Layout shifts, dark modes, animations, and transitions are just some of the ways in which functions make our lives oh so much easier. Functions allow developers to account for window resizing and a whole host of situations that were either impossible or very difficult to handle with traditional CSS syntax.

If you are a fan of the readable, nested structure of HTML, have you ever wondered why CSS was so…wide? You are not alone. SCSS lets you write your CSS logically nested; it works exactly as you think it does. Furthermore, mixins and the Extend/Inheritance functionality of SCSS allow you to treat your classes as you might treat prototypal inheritance and the spread operator from ES6 syntax in JavaScript (but not quite the same). Placeholder classes work to reduce bloat by allowing developers to create utilities that are only transpiled if used. This takes care of cleanup of unused classes (we all lose track at some point) and makes writing CSS a pleasure. By the same token, mixins further improve the experience by behaving as a function where the operant variable passed by default is the browser context, making your stylesheets much easier to maintain and reducing the complexity of cross-browser compatibility for you at least somewhat.

_partials and _modules

Ever gone toe-to-toe with a monolithic beast of a stylesheet? No fun. Partials and modules allow developers to refactor ludicrously long stylesheets into logically separated, manageable chunks that can be scoped as needed. Fundamentals of writing good code (separation of concerns, modularity, maintainability, DRYness etc) are not only good hygiene but essential to maintaining our sanity, why wouldn’t the rules apply to CSS? They do now!

The New Kid on the Block – PostCSS

If you’ve kept your ear to the ground, you’ve no doubt heard of PostCSS; I had many misconceptions about what this library actually did in the beginning, but when I finally understood its function and place in the stack, it blew open doors I my head I didn’t even know existed. I initially thought PostCSS was some kind of preprocessor and left it at that. Man was I wrong. PostCSS is not a preprocessor, even though it can act like one if you want it to.

PostCSS converts your CSS into a data object you can then manipulate with JavaScript!

In a sense, PostCSS sets the stage for limitless possibilities regarding manipulation and processing of your stylesheets. It abstracts your syntax into something you can write plugins for called an abstract syntax tree. C’mon, that just sounds cool. Functionally, this allows you to process your stylesheets in any way you see fit with the help of popular build tools and task runners such as Webpack, Grunt, and Gulp. The most famous of these plugins (which you probably use without knowing it) is Autoprefixer, the processor plugin used to append browser prefixes to all your CSS classes, handling the dreaded task of cross-browser compatibility in one pass! PostCSS has a diverse and rapidly growing ecosystem of plugin packs which do everything from simulate color blindness for accessibility testing of your UI to the now popular Lost grid system by Cory Simmons. Suffice to say, if you ever meet Andrey Sitnik, Ben Briggs, or Bogdan Chadkin in person, buy them a beer! This stuff is awesome!

Moving forward, the future of CSS is bright and has no doubt accelerated over the last couple years. If you write any PostCSS plugins let me know! I’ll do my best to contribute where I can!

Additional reading

If you're interested in this article, check out some awesome reference material below!

Related resources:


Interested in more tips like this? Check out A beginner’s overview of DevOps.
Back to the blog