What Happened to Separation of Concerns in Frontend Development · Jens Oliver Meiert

By admin
What Happened to Separation of Concerns in Frontend Development


Nicole Sullivan
PERSON

recently asked the community whether separation of concerns (

SOC
ORG

) was still serving us.

58%
PERCENT

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 only started to work well once many stopped focusing on it,

about 10 years ago
DATE

,” because then, “we got ever better CSS selectors and support for them, and

JavaScript
PRODUCT

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
ORG

.” 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.

What Enables and What Prevents SOC


First
ORDINAL

, 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
ORG

, everything related to behavior in

JavaScript
ORG

, and the touchpoints of the

three
CARDINAL

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
ORG

, and

JavaScript
ORG

(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
DATE

, and it’s easy to do now, but we had a few websites where it was actually done in

the 2000s
DATE

, and many where it’s not respected

today
DATE

. That’s on engineering principles and culture, not on web standards or browser support.


SOC Improvements Through Web Standards
ORG

The easiest way to gauge improvements, now, may be by looking at

CSS
ORG

selectors and their support. This is because all websites use HTML, but more websites also use CSS than they rely on

JavaScript
PRODUCT

; and it’s because the less need there is for classes and IDs (the prevalent selection options), the more opportunities there are to more fully separate HTML and

CSS
ORG

, and therefore concerns.

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
ORDINAL

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:

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
DATE

: Around that time, CSS

2.1
CARDINAL

matured, and work on CSS Selectors Level

3
CARDINAL

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 significantly easier starting at around

2010
DATE

.

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
WORK_OF_ART

, and later extended):

There have been many more frameworks released in

2010
DATE

(

±4 years
DATE

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

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
CARDINAL

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 equip it better 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 concerns.

Before I conclude, I need to call out again that more data would help. I worked with ballpark numbers for

CSS
ORG

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
PERSON

’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
PERSON

for reviewing this post.

About Me

I’m

Jens
PERSON

, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like

Google
ORG

, I’m close to W3C and

WHATWG
PERSON

, and I write and review books for

O’Reilly
ORG

and

Frontend Dogma
ORG

. 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!