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.
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! ✌
Latest comments (8)
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"?
Sounds good!
Updated! :)
The codepen demo is worth a 1000 words.
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.