One great aspect of the web development community is that there’s always someone posing a challenging thought. That initial prompt inspires many responses, which in turn inspires more responses. It’s like our very own version of the Roxanne Wars, albeit with fewer rhymes and no dope beats, but maybe more example CodePens or JSFiddles.

Often, this discourse serves as fodder to commiserate with colleagues. We roll our eyes. We point to random tweets or blog posts, claiming said author a fool. We react too quickly before considering the opposing point of view. However, I honestly think being challenged is an important part of pushing the community and the technology we use forward.

Having said that, let’s talk about CSS-in-JS. 🔥

A couple weeks ago, the developer Remy Sharp pondered the need for CSS-in-JS:

At this point, if you’re wondering ‘What the hell is CSS-in-JS’, I’d encourage you to jump back to the first paragraph and follow the link to the Roxanne Wars Wikipedia page. Otherwise, this post is not going to make a lot of sense, and you’ll waste your time reading about a very obtuse subject you probably don’t need to care about. Your life is way better not knowing or caring. Trust me. 😃

Are you still here? Awesome. Let’s continue.

Remy’s tweet inspired many responses.

In the “I’m not sure about this CSS-in-JS stuff” corner, Chris Ferdinandi wrote about it a few times offering good insight to why he’s dubious about the approach. He also, outlined his thoughts in a quick 15 minute podcast. The designer/developer, Brad Frost agreed with Chris, asking the same question.

Remy’s tweet as well as Chris and Brad’s thoughts inspired many responses from the “Are you kidding, CSS-in-JSS is awesome” folk. Two that resonated with me the most came from Brian Muenzenmeyer and Micah Goldbolt.

All these posts are worth reading and thinking through.

My concerns about CSS-in-JS

Overall, I have issues with CSS-in-JS. My concerns aren’t necessarily around the idea of writing CSS within a Javascript file. More so, I worry whether we’re relying on technology as a replacement for fundamental knowledge.

In his What’s right with CSS-in-JS post, Micah Goldbolt has a couple observations that speak to my concerns:

I agree that you’ll sometimes find JavaScript developers writing markup and styles who know very little about proper semantics and accessibility. But I would argue that this is at most a warning to always keep front-end minded developers involved in your markup and styles. If moving styles to JS makes you think “great, now all we need are more JS developers on this project”, you are sorely missing the point!

In my experience, this situation is real, and a problem.

In the age of the full stack developer, I’ve found core HTML and CSS skills are often the pieces of the stack that are punted on. I’ve worked with a lot of developers during my career. Most are extremely talented, doing things that made my head spin. I’ve also spent a lot of time removing <div> elements from their markup, replacing them with semantic HTML. Unfortunately, hooking up an interface is prioritized over ensuring the product is built from a strong, semantic foundation. Again, this is my experience. You might work for an organization where this isn’t an issue.

While I’d wish these developers took more care and time to understand these basics, I’m not necessarily criticizing them. It’s virtually impossible for anyone in tech to master the full range of a given tech stack.

I’d place this deficit upon organizations to realize that an engineer connecting a Mongo database, might not also be the best person to write the HTML and CSS. However, unless that organization gets hit with a costly ADA lawsuit, they probably won’t ever come to this realization and take action. And, if the organization IS hit with an ADA lawsuit, then they’re untangling years of product development, potentially rebuilding the entire product at a cost that is much more expensive than starting from a place of prioritizing an accessible product.

Micah suggests to keep “front-end minded developers involved in your markup and styles”. My concern is that we’re too eager to consider the fundamentals less important as the front end continues to change.

All this might seem like a hyperbolic jump in logic. Afterall, we’re supposed to be talking about writing CSS, right? If we’re being honest and acknowledging that developers struggle with CSS, is technology the best solution? Are we causing more issues for ourselves six months to a year from now?

Another point Goldbolt makes in his article is the challenges of using reusable mixins and functions:

… I agree that writing our styles in JavaScript makes them less accessible to other components wanting to reuse variables, mixins and functions. The variable problem can certainly be remedied by moving those important values into Tokens (or some JSON’esque file that JS and Sass can read). Mixins and Functions, on the other hand, are more difficult to produce cross platform and will either need to be duplicated, or accepted as a ‘lost in translation’ casualty.

For me, this is huge. Teaching a developer to use a system of mixins is easier and more predictable than teaching a developer the specifics of flexbox, grid or the simple act of styling a button.

I’d rather provide that developer with the opportunity to do something like this.

.my-special-button {
   @import button(primary);
} 

A system of mixins preserves the notion of a single source of truth. Whoever writes the mixins is charged with the maintenance. The end-user developer is only concerned with choosing the correct variant. Losing reusable bits via mixins might be my largest concern with a CSS-in-JS approach.

Beyond the specifics of writing CSS in a Javascript file, is the attitude many developers seem to have about CSS, overall

It’s almost like there is an assumption that CSS shouldn’t be hard. After all, it’s just colors, sizes, space and other silly visual stuff like that. Fact is, CSS takes time and care. To get good at it, you need to work hard. I don’t think many developers get that. I’ve written lots of CSS, and I make mistakes … daily … or hourly. While JS developers are labeling CSS as inferior, I’d encourage them to think about the daily struggle they have with JS. It’s a tremendous language, but that shit ain’t easy, either. I often get the impression that CSS-in-JS is viewed as a panacea, freeing developers of the scourge of CSS.

And then there’s the fact that CSS isn’t a programming language.

Proponents of CSS-in-JS, like to throw out the “at-scale” argument. When do we reach a point where we can say we’re at scale. A developer at Facebook might have one idea of at scale, while a developer at Bob’s Awesome Single Page App, LLC, might have another. It’s subjective, rather than absolute. I architected and wrote the CSS library that powers the Uniform Design System. I’d assume that’s “at-scale,” and we didn’t utilize CSS-in-JS for our React components. 🤷‍♂️

Many CSS-in-JS approaches inject <style> tags into the <head> of the document. This practice makes me wonder where are are in terms of performance considerations. By making all our styles critical path css, we risk making none of it critical path. Are we less concerned about performance than we were just a couple years ago. In most cases, these styles can be extracted into an actual CSS file, but I’ve rarely seen this happen.

Final thoughts

I see the value in an approach that encapsulates style and keeps developers from wrestling with the cascade or the global nature of CSS. The web and the products we make are so much more complex than they were when we strived to keep a defined separation of our concerns: Javascript, HTML and CSS.

If the decision were left up to me, I’d keep CSS out of JS. I’d rely on a naming convention (probably Block Element Modifier), modular files and a system of mixins and functions. I’d help developers write less CSS while helping protect them from all the things they struggle with while writing CSS.

Whether an organization adopts an approach like CSS-in-JS or not, it should be a group decision. It should be a decision that satisfies the needs of the entire organization, not satisfying the desires of a few individual developers eager to experiment with a different technology.

One consideration I always ask others and myself when adopting a new technology is what happens when we step away from this technology? I don’t expect an immediate answer, but stopping to think about this, is worthwhile.

Historically, we’ve relied on Javascript to give us what the HTML or CSS specs don’t. Smart JS developers gave a options for responsive images long before the standard was settled and implemented. JS is giving us options for element queries, taking responsive design to new, exciting places. Javascript has been, and will continue to be, the proving ground for these crazy ideas our community creates.

I clearly have my reservations with this CSS-in-JS, but I love that paradigms are constantly challenged in our industry … as overwhelming has that seems at times.