Cover image for Concerns with Separation of Concerns

Concerns with Separation of Concerns

pulljosh profile image Josh Pullen Updated on ・2 min read

Gasping Grouping (2 Part Series)

1) Concerns with Separation of Concerns 2) How Portals Will Restructure the Internet

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

Gasping Grouping (2 Part Series)

1) Concerns with Separation of Concerns 2) How Portals Will Restructure the Internet

Posted on by:

pulljosh profile

Josh Pullen


I love web development! If you ever want help with anything, please message me here on Dev, on Twitter (@PullJosh), or by email (hello@joshuapullen.com)


markdown guide

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.


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.


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


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

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


The codepen demo is worth a 1000 words.