Components and concerns
We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.
It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.
But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:
Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.
This echoes a point made previously in a slidedeck by Cristiano Rastelli.
Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?
There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.
In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:
Your starting point should always be well-structured markup.
This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.
That’s basically an application of starting with the rule of least power.
In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
- Enhance!
That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:
We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”
There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.
My point is this:
- Separating structure, presentation, and behaviour is a good idea.
- Separating an interface into components is a good idea.
Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.
This was originally posted on my own site.
