We have a problem in the front-end landscape. I mean, here we have an entire library designed to make CSS immutable. The problem is, mutability isn’t a bug in CSS, it’s a feature – heck, it’s arguably the central feature! The cascade is literally in the language’s title; trying to remove that seems like madness. What’s worse is the reasoning given, these so-called “side effects” of CSS:
- Selectors clashing with other selectors;
- Selectors targeting unwanted elements;
- Styles overriding other styles;
- Elements inheriting undesirable styles.
All of these things are central concepts to the cascade. Without them, CSS ceases to function as CSS and returns to, well, inline styles with I guess some loose variable functionality. That’s a huge step backwards in terms of usability and behaviour. It also completely erodes one of my core skillsets and invalidates it as a "bug". * grumble, mutter, grumble *
Chris Coyier recently summed up a lot of these feelings of othering and misunderstandings within the front-end space in his now universally discussed article The Great Divide. Reading it myself, it rang incredibly true. Chris has put into words some things which have been floating around in my brain for a few months.
.html file; you might later convert that to
.php to hook in a CMS, but all that really meant was changing the file extension and adding a couple of lines of code. Heck, I remember when Notepad++ was some super fancy new thing that introduced major features like auto-tag closing and coloured text! Now, in order to “spin up” a simple, personal website, I’m advised to know Git (and have a GitHub account), install npm or yarn, and wrangle a list of dependencies as long as my old
index.html file was. God forbid if anything doesn’t install correctly, or if a project has been updated since the tutorial was written/recorded and no longer works in the same way.
As part of a project for work, we’ve ended up building an internal company hub using a raft of these new technologies. The website itself is an SPA built with React, meaning a local dev environment requires Node, yarn, Prettier, ESLint and a stack of other tools. It’s synchronised to our GitHub account, which is integrated with a deployment pipeline on Heroku. There’s a lot to love about that setup, and once you have it all working it feels great; a couple of commands in the terminal and I’ve deployed our latest edits, fully tested and “prettified”, to a live server. No more battling with WAMP or SFTP, no more having to login to cPanel every time you need to change a file. In many ways, tooling around web development has gotten a lot simpler and more user friendly. But, at the same time, what we have is effectively a three-page website with header panel, navigation pane, and main content area; the entire thing could have been built with one stylesheet and three HTML files. Sure, it wouldn’t be quite as slick, but the user experience would be practically identical (in fact, arguably better, as what we’ve ended up with lacks some core accessibility features and isn’t – yet – responsive, whereas HTML/CSS would have done both straight out of the box).
Do I think that my colleagues were wrong to go down the "modern" route. No, I don't. I think there are reasons why a React SPA could become useful in the future. What we've built is an MVP and it shows, but the additional functionality that has been suggested would make use of React's special powers. That said, aspects of the setup were a complete headache. Friction has been removed from some areas of the development process but they've been replaced with new stumbling blocks.
To a degree, that would be fine. I'm all for reducing complexity and believe the front-end world needs to adapt to survive and thrive. My worry is that those skills still feel pretty fundamental to how the web should work. CSS is an easy one to point to in terms of skill erosion, but it feels like web performance, accessibility, progressive enhancement, and many other core web concepts are being taken along with it, just more subtly. I believe the web should be open and accessible, not just for the user but for the developer. Right now, it feels like the dominant conversation is one about making it harder to access, and that disappoints me.