What Happened to Separation of Concerns in Frontend Development

Published on October 5, 2023 (↻ December 14, 2023), filed under (RSS feed).

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):

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.

Toot about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. 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.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!