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.
I come from the background that Chris keeps talking about, what you might refer to as "traditional" web development. I started with HTML and a little JavaScript, branched out into semantic HTML and CSS, built up a good knowledge of jQuery, and then left the web for the best part of a decade. When I returned it was to find an ecosystem I barely understood. In the “old days”, starting a new project on the web was as simple as opening Notepad and saving a .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.
I've seen a lot of the discussion around concepts like CSS-in-JS and the "great divide" boil down into what's easiest for development teams. CSS-in-JS is just "easier" to understand; using JavaScript everywhere is "easier" to hire for and gives a greater level of control. But I agree with Chris in that the term "easy" here is being targeted at a specific skill set and a specific mindset. Some people find engineering concepts like MVC highly intuitive; others find the cascade in CSS very simple. Some people definitely bridge that gap and can work in both areas. Personally, I fall into the latter camp; CSS has always felt natural to me, whereas I'm capable of understanding engineering concepts, but it's something I need to actively learn. Right now, it feels a little like people in my camp are being actively removed from the conversation. Our skills are being ignored or diminished, "bug fixed" out of the web.
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.
