In my last article I covered how difficult it is to choose a CSS methodology or framework at present, and made my case for why avoiding dogma is among the most important thing we can do as a community to make new discoveries and move CSS development forward.

Javascript Does CSS

It was Håkon Wium Lie who first proposed the concept of Cascading Style Sheets while working at CERN in October of 1994. CSS was later formalized by Lie in his PhD thesis at the University of Oslo 2006.

In a question and answer session following a CSS lecture Lie presented on February 16, 2006 — the day before his thesis defense — a surprisingly prophetic bit of back and forth occurred:

Ethan Munson: But I do think you have identified the essential problem

which is, whatever you propose it is going to take a while to get into

any browser. I mean, you can propose it, and if you actually want it

to be a standard, Opera maybe will have it working by the time the

standard is endorsed but the other browsers manufacturers probably

not, and until you have almost all the browsers running something it’s

not running. HWL: That’s right. There is an alternative that would work today, and

that’s to extract things into Javascript libraries, which you had well

written Javascript libraries that you could refer to, today you would

have it working even IE6. Again you would have to hold your nose, some

of us would have to hold our noses, for that to happen but it is

something that could be done more easily. I think we actually have to

pursue both these ways. I think we’re gonna have to get more into CSS

but not hold our breath for it to be used. Ethan Munson: What if you could make the transition smoother? What if

you could, this would be ugly code, but what if you could add the

features to CSS that you want but make a path by which someone could

use a Javascript implemented parser to identify the presence of that

code in the CSS and can support it with a Javascript library?

— Style sheets and the challenges related to the dynamic aspects of the

Web

As we all know CSS went on to become the method for defining how a web document should be styled. It was powerful enough to meet the needs of web developers working on all types of projects, and was accessible enough for tinkering web dev hobbyists to get to work without a giant learning curve.

CSS also provided a nice and neat Separation of Concerns for each piece of what became the holy trinity of web documents: HTML, Javascript, and CSS. HTML handled structuring content, JavaScript provided behavior, and CSS dictated how everything looked.

This setup provided an excellent, battle tested solution for publishing webpages for many years. It was robust, had a low barrier to entry, and made web development approachable. All was right with the world wide web.

Advancements in JavaScript however introduced an entirely new development ecosystem over time. By 2011 the rise of JavaScript frameworks for building Single Page Applications began to affect the development landscape. AngularJS emerged in October of 2010, EmberJS in December of 2011, ReactJS in March of 2013, VueJS in February of 2014.

Between 2011 and 2014 the development landscape shifted away from web documents —sites that are primarily static content — and continued further into the realm of Single Page Apps as the popularity of these frameworks grew. As SPAs matured in their complexity and behavior, users began to expect sites to have more and more dynamic, feature rich experiences.

In November of 2014, Facebook engineer Christopher Chedeau aka Vjeux, gave a talk on a concept he called CSS-in-JS. He opened the talk with what has become a rather famous slide, outlining what he saw as the major problems with CSS that needed to be overcome so that developers could sanely maintain highly dynamic web applications, particularly at scale:

Vjeux’s 7 Problems with CSS at Scale (https://speakerdeck.com/vjeux/react-css-in-js)

Since 2014, many developers have worked to make CSS-in-JS a reality. Processing CSS using JavaScript provides a unique solution to these problems. If you’d like a deeper dive into current implementations, and the pros and cons of using CSS-in-JS methods, I highly recommend Indrek Lasn’s great article All You Need to Know About CSS-in-JS.

Using Javascript to apply and manipulate CSS at first glance appears to violate the Separation of Concerns principle. In Cristiano Rastelli’s excellent work Let There Be Peace on CSS (article / video) he suggests that CSS-in-JS keeps the Separation of Concerns in tact. We simply have to slice our concerns differently. Consider if concerns were being divided along element lines instead of technology lines. We still end up with a clean separation:

Separations of Concerns from a Different Point of View (Let There Be Peace on CSS)

Document vs. Web Apps

“Anyone who has worked with CSS long enough has had to come to terms with its aggressively global nature — a model clearly designed in the age of documents, now struggling to offer a sane working environment for today’s modern web applications.” [The End of Global CSS]

There are roughly speaking two types of websites on the internet: those that are made up of primarily static content (documents) and those that are primarily interactive (web apps). In Mark Dalgleish’s The End of Global CSS he argues that the CSS specification, which is a direct descendant of the spec that was created and ratified in the late 90’s does not adequately meet the needs of modern web apps.

Building a Document site and building a Web App each come with their own needs. If traditional (non-CSS-in-JS) CSS meets the needs of your project, carry on! Indeed, even if you are building a Web App, there are multiple thoughtful arguments made in defense of traditional CSS over CSS-in-JS.

Every project has distinct needs, and every developer has unique preferences. The question then should not be “will CSS-in-JS or traditional CSS win the CSS wars?” but rather “which CSS solution aligns with my project’s needs?”

I believe the closing statements of Cristiano Rastelli’s Let There be Peace on CSS express this better than anything I’ve read:

I am not in the position to influence an entire community like ours. But I can try to convince you that there is a better way than fighting each other. So, here are my suggestions: 1. Embrace the ever-changing nature of the web. 2. Be careful with your words: they can hurt. 3. Be pragmatic, non dogmatic. But most of all, be curious.

If we can embrace the ever-changing nature of the web, we can more easily find empathy for our fellow developers. By choosing our words carefully we can avoid needless insult and encourage healthy debate. By valuing pragmatism over dogma we can keep an open mind to new concepts. By being curious we can discover new things worth sharing, while simultaneously evolving and maturing our toolset.