What Happened to Separation of Concerns in Frontend Development

Published on October 5, 2023 (↻ December 14, 2023), filed under Web Development (RSS feed for all categories).

Nicole Sullivan recently asked the community whether separation of concerns (SOC) was still serving us. 58% responded that it “still works,” but the topic looked more complex and interesting than that.

My own feeling and response was that there was a “great irony”—that “separation started to work well once many stopped focusing on it, about 10 years ago,” because then, “we got ever better CSS selectors and support for them, and JavaScript was being significantly improved,” but “it was also the dawn of the frameworks time […] that accelerated and eventually undid most focus on things like SOC.” I submitted that “separation may have never done better—and also never worse.”

Is this what happened with separation of concerns, in our field? Could I substantiate this feeling? Let’s have a look.

Contents

1. What Enables and What Prevents SOC
2. SOC Improvements Through Web Standards
3. SOC Regressions in Frameworks
4. The Great SOC Irony

What Enables and What Prevents SOC

First, what actually helps or prevents separation of concerns?

The answer appears to be both easy and difficult.

It’s easy when we go by “everything related to document content and structure is done in HTML, everything related to presentation in CSS, everything related to behavior in JavaScript, and the touchpoints of the three are limited to the absolute minimum necessary.”

It’s difficult when we go by the specific steps that enable and prevent separation, because separation depends on specific features of each HTML, CSS, and JavaScript (i.e., the different ways they intersect with the other languages), but also on engineering principles and culture. Separation of concerns stands and falls with being sought and practiced.

That is, it was hard to accomplish good separation of concerns in the 2000s, and it’s easy to do now, but we had a few websites where it was actually done in the 2000s, and many where it’s not respected today. That’s on engineering principles and culture, not on web standards or browser support.

SOC Improvements Through Web Standards

The easiest way to gauge improvements, now, may be by looking at CSS selectors and their support. This is because all websites use HTML, and more websites also use CSS than they rely on JavaScript; and it’s because the less need there is for classes and IDs (the prevalent selection options), the higher the probability that HTML and CSS (and therefore concerns) are being kept separate.

In other words, the hypothesis is that in frontend development, we observe the least separation of concerns, and most mingling of them, around presentational markup—and that one way to limit the amount of presentational markup is by providing more effective selectors.

Gauging, however, how the situation with respect to selectors developed is finicky, time-consuming, and error-prone, as it would require going by each selector; and then looking at not when it was specified, but when it was first supported; in each user agent; then researching and taking into account their respective market shares.

Perhaps we can do with something more rough, but still telling:

CSS Spec	Number of Selectors	Year of First Spec Draft	Year of Spec Release
CSS 1	10+	?	1996
CSS 2.1	22+	?	2011
CSS Selectors Level 3	41?	2009?	2018
CSS Selectors Level 4	70+	2011	?

Important: I was very quick with this, looking more for ballpark numbers than anything. I’ll be more than happy to accept corrections and additions, if you’d like to provide feedback!

So this is all rough, but there is some interesting clustering around 2010: Around that time, CSS 2.1 matured, and work on CSS Selectors Level 3 and 4 commenced. Very roughly, too, we can suspect improved selector support during these and the following years.

That is, there are some indicators that separation of concerns, between HTML and CSS, may have become much easier starting at around 2010.

SOC Regressions in Frameworks

Let’s now look at frameworks, to check if there’s something to the idea that their emergence worked counter the options to separate concerns that we received from CSS.

For this reason I reviewed around 60 frameworks (including the ones I covered in The Little Book of HTML/CSS Frameworks, and later extended):

• Base was released in 2012 and uses presentational class names
• Basscss was released in 2013 and uses presentational class names
• Beard was released in 2014 and used presentational class names
• Blueprint was released in 2008 and used presentational class names
• Columnal was released in 2011 and used presentational class names
• Foundation was released in 2012 and uses presentational class names
• Groundwork was released in 2013 and used presentational class names
• HTML KickStart was released in 2012 and used presentational class names
• IVORY Framework was released in 2013 and used presentational class names
• KNACSS was released in 2013 and uses presentational class names
• kouto swiss was released in 2014 and used presentational class names
• Materialize was released in 2014 and uses presentational class names
• MetroUI was released in 2012 and uses presentational class names
• Picnic CSS was released in 2014 and uses presentational class names
• Responsee was released in 2014 and uses presentational class names
• Skeleton was released in 2011 and uses presentational class names
• Tachyons was released in 2014 and uses presentational class names
• Titan Framework was released in 2013 and used presentational class names
• Tuktuk was released in 2013 and used presentational class names

There have been many more frameworks released around 2010 (±4 years) so this isn’t a complete list, but let’s stop here.

We do have some indicators, then, that since around that time we had a number of frameworks that did not separate concerns, but mingled them instead.

The Great SOC Irony

So what happened, and can we speak of irony, then, around separation of concerns in frontend development?

It does seem so. Separation of concerns used to be quite hard, and one of the most limiting factors had been selector variety and support.

But just when that changed, and more CSS selectors were introduced and supported, we observed a large number of frameworks tie presentation to structure, specifically by use of presentational class names.

Instead of using the new selectors (or, to be clear, fewer, functional, or generic class names) to make the markup lighter and optimize it for future CSS-only redesigns, the frameworks gave that opportunity away and guaranteed redesigns to require HTML updates. Their tight coupling meant the opposite of separation of concerns.

❧ Before I conclude, I need to call out again that more data would help. I worked with ballpark numbers for CSS selectors, and couldn’t analyze “all” frameworks. More data could support the hypothesis, or demand a different one. (Furthermore, one could gather a selection of instances where separation of concerns has actually improved.)

In the end, I’d like to underscore what the majority expressed in Nicole’s poll—separation of concerns “works.” It could work even better if we had broader support for ancient but awesome features like style sheet references in HTTP headers (example and context), but:

Separation of concerns works better than it ever has. We—and our tooling—may just not be making good use of it.

Many thanks to Lars Knudsen for reviewing this post.

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.