Getting fast at building frontend means going beyond trying to make something work as quickly as possible. Aiming for speed instead of efficiency makes learning CSS more difficult today than it was twenty years ago. It’s not because the language evolved but because the many shortcuts get us stuck in bad practices.
Flogging frontend #
CSS is a language with which we can make something appear in the browser and mistake it for a job done, even a job well done. If frontend development is about producing things we can see (which it is not), we expect it to be as fast to write as drawing or assembling from ready-made pieces. And we seek to become faster rather than better.
While speed can be a case of proficiency, it is not a measure of proficiency. Speed means little compared to quality. If we aim to get things working as quickly as possible because we are chasing tasks, we are unlikely to write quality code. It doesn’t have to be because we rush the work but because we employ methods to work around our issues. And if we don’t see those issues as a result of how we use the language but instead interpret it as a messy process, it isn’t easy to improve ourselves. It’s difficult to see what we don’t know when what we do seemingly works.
The beginner’s example in The concept of logic works because we flogged the HTML and CSS until they yielded. When that becomes our experience, we will continue doing it, and we get this mess with !importants, specificity issues and selectors flying all over the place overriding each other. We end up with a rolling snowball of CSS that gets worse by every turn, although the frontend seems to work. No wonder we are led to think the language is broken.
CSS-not-CSS #
One way of flogging frontend is using CSS not written as CSS. Numerous developers have built scaffolding around a language to pretend it works like they expected it to instead of learning to levels where they write code without their possible issues. A library or framework becomes a positive experience for us when it lets us build faster while keeping the beginner’s single-element focus and with less frustration because it’s super-scoped.
It doesn’t increase the quality; we employ even more code, we just don’t feel like we’re flogging the CSS anymore. While we don’t have to see the mess ourselves, our users have to deal with it every day. And when things break, we have to start digging through it and discover that the library, framework or design system actually fights cascade, inheritance and general logic.
Instead of systemised CSS, we risk ending up with systemised bad habits that make it harder to use the language’s features and concepts. While many tools can provide some entry-level learning, most are trend-based shortcuts to frontend; and there are no shortcuts to good frontend. As abstracted subsets and not feature complete alternatives of the language, they soon become detours on our way to learning and understanding.
There is no way around CSS and HTML when we build the web. Keeping its programming languages at a distance does not make us better developers. We’re just using perpetual training wheels that allow us to keep up the bad practices. And we don’t need training wheels for these languages to begin with.
Good CSS #
Good CSS is in use. CSS that is overridden is not in use. Most utility classes are not in use. Scoped CSS is rarely in use. The better we master the language, the better we become at figuring out when to do what for the thing we are working on. If the thing we are writing is not CSS, chances are it leads to bad CSS.
When we start to grasp the language, we are on our way to writing CSS that surpasses any CSS-not-CSS technique. We do it faster than we produce something with any framework, and we write more usable, reusable and accessible frontend code.
Ignoring trends but picking the tools that work for our project can be daunting when we are insecure about making the right choices. But we can never go wrong with aiming to write our own CSS. And knowing it well makes us better at setting up the right tools, even if that includes someone else’s code.
Nothing’s broken #
The road is shorter to solutions that allow us to continue working with our misconceptions than the ones that challenge them. If we conclude that CSS is supposed to be messy and complicated because we have been writing code since some time between the late nineteen hundreds and last week but never gotten the hang of it, it’s hard to believe we’re doing anything wrong.
Luckily, neither CSS nor we are broken, but our processes can be. The best thing we can discover about a language is that we still have much to learn; then, we can explore what quality means today and who it affects in the future.