Do you hate or love The Cascade in CSS? It's the eternal flame war of frontend development.

Look, a lot of smart people have been involved in writing the specs for CSS, and evolving it to meet the needs of today's applications. And if you listen to them, you may start to get an appreciation for everything the cascade gives us.

Jen Simmons is one such very vocal person about how many features of the cascade helps us to write more resilient CSS that works on every browser, every device, old and new. She's right that this is a massive benefit that we often don't think about. The web itself doesn't become obsolete like our hardware does, and the fact that we can still see websites from the 1980s and will be able to continue making websites well into the future is wild! Not many technologies can claim this kind of longevity and resilience to change. We should celebrate this about CSS, and not write it off as some wacky, weird cousin whose shenanigans we merely tolerate.

This resilience comes from the fact that the cascade is designed to resolve conflicts. Given multiple inputs from multiple sources – the browser, the user, and the code author – the cascade determines what should be the end result, and the end result is never an error. That's right, you don't have disappearing elements or 500 errors, your website still works!

So the cascade (and all the people who have and continue to work hard defining it) 1000% deserves props for all that it has enabled. It definitely helps to be reminded of that!

But the tradeoff for that resilience and flexibility is a more complex authorship experience, and this is why I both love and hate CSS. The power of progressive enhancement usually requires us to use overrides, and if it's just me writing the CSS, I can make sense of what's going on and why I've used a particular override. But CSS usually gets written in teams, and frequently is authored by developers who have only cursory knowledge of CSS. This is where things start to get tricky.

Learning to write good quality CSS that can be understood by others requires discipline, just like writing quality code in any other language. But CSS is systematically devalued, and this is plain even when we talk about what skills a "frontend developer" should have. So we end up with big balls of mud, lots of dead code, and with minimal tooling to help us figure out how to begin cleaning it all up. Debugging CSS is annoying and time-consuming, even when you're good at CSS. It can be hard to know when a line of code was added for legit reasons, or because previous developers were flailing wildly to get things looking like the mock-ups.

I do think the nature of the cascade enables a lot of wild flailing, and in moments of frustration, I'll admit that that makes me hate it like the so-called boiled carrot. There are ways around this: specific engineering techniques that can help us write understandable and proactive code, that we can modify with confidence. That we can now add CSS Layers to this list is evidence of how CSS is rising to meet the challenges of web development today! The trouble is convincing the rest of the team that there is value in doing this work. And convincing them is just the first step; we also have to figure out how to close the skills gaps. I've been there, and it does get tiring fighting the same fight, team after team.

So where do we go from here? The emergence of design systems has shown me that, as an industry, we are starting to care more about the UI developer experience, as well as understand the benefits of platform thinking in a UX context. I'm hopeful that design system teams will attract more developers with HTML, CSS, and accessibility skills, as a way to amplify their impact. I hope to see more improvements to CSS tooling (including browser dev tools) emerging from this space that isn't just more CSS-in-JS. And, I'm excited for the future of the CSS specs that will help us engineer more robust CSS.