DEV Community

Cover image for Concerns with Separation of Concerns
Josh Pullen
Josh Pullen

Posted on • Edited on • Originally published at joshuapullen.com

Concerns with Separation of Concerns

The Old Way: Splitting Code by Language

Before components were cool, we often split our code up into separate HTML, CSS, and JS files. This division kept tangles of related code pulled apart into separate chunks with only the necessary strings between them.

Splitting code by language was better than putting everything into one file because it lowered the stress on our scroll wheels and allowed us to sleep at night under the false presumption that our code was properly organized.

But the connecting strings were there, and they haunted us.

All three languages were necessarily intertwined (if you change a class name in HTML, you have to update your CSS and JS too), so we were constantly jumping back and forth between related files.

The New Way: Splitting Code by Component

A far better system, with less jumping involved, is to split code up based on what goes together. Components help us do that! Components are a recognition that splitting up our code into files based on the programming language is the wrong approach.

It was controversial in the beginning. There were outcries. The public made clear that such a convolution of concerns was an infringement on the very foundations of a civil society.

Dan the Witch

For a while we were convinced that this generous bloke was actually a witch!

But, as it happens, combining HTML, CSS, and JS all together is actually a really great idea. The key condition? You must instead divide up your code based on which pieces of HTML, CSS, and JS work together to form a coherent whole. That's what happens when we split our code into files at the component level.

The key benefit is that we no longer have strings attached between each of our files. (If we change a class name, everything happens in one place.) In an ideal world, every component is entirely self-contained and does not rely on the implementation details of other components to function properly. This means that we no longer need to jump between files nearly as often.

Change is the Only const

Changing deep-rooted ideals (about, for instance, separation of concerns) is incredibly difficult. Fortunately, web developers seem to be quite good at it. The industry moves fast, and it can sometimes seem like we're reinventing the practice too often. But looking back at old ideas is a reminder that the adaptations are worth the pain. Keep up the good fight, y'all! ✌

Top comments (8)

Collapse
 
niorad profile image
Antonio Radovcic

Also nowadays there are fewer front-end-devs without JS-knowledge than some years ago. The HTML/CSS-only role may still be alive here and there, but for the majority of positions JS is required. This makes jsx/css all in one component more viable I guess.

Collapse
 
szabototo89 profile image
Tamás Szabó • Edited

The article title is a bit misleading because you don't really explain why JSX is a better choice than other frameworks (Angular/Vue.js). E.g. Angular or Vue.js is also separating your code based on components, still, they've got HTML/CSS/JS separation either.

Collapse
 
pulljosh profile image
Josh Pullen

That's a good point. Any ideas for a better title?

Collapse
 
szabototo89 profile image
Tamás Szabó

How do you like this: Separation of concerns in web development?

Thread Thread
 
pulljosh profile image
Josh Pullen

That seems like it's on the right track. What about "Concerns with Separation of Concerns"?

Thread Thread
 
szabototo89 profile image
Tamás Szabó

Sounds good!

Thread Thread
 
pulljosh profile image
Josh Pullen

Updated! :)

Collapse
 
dance2die profile image
Sung M. Kim

The codepen demo is worth a 1000 words.