This is the last entry in the series on CSS methodologies, so it’s time to share some thoughts that arose in the result of learning about this topic.
Currently, many web applications are created using the React and Vue libraries, as well as the Angular framework. What connects them all and shadow DOM is to divide the application into components, i.e. independent fragments. Each component has its own JavaScript code, HTML code and CSS code. And let’s focus on the latter. We use the styles corresponding to this component to change the view of this component only, no other. And if so, do we need CSS methodologies if the component approach divides the CSS code into specific blocks? My answer is yes.
Methodology is more than just code breakdown
From the very definition of methodology, we know that it is a set of rules that enables solving a specific problem. In our case, the problem is to write readable, reusable code. The solution is the rules that force us to approach it properly, enclosing us in a specific, predictable pattern. The division is the result of implementing the rules. Let’s use BEM as an example – if we look at BEM and the requirement to use semantic classes, then naturally we get the code breakdown, dictated by the names of the classes.
An application is a collection of components
For the application to be visually consistent, some styles must be the same for each component. I mean, for example, font, shadows, general colours, paddings, margins. If each of the CSS files for individual components would have to contain code defining the listed values, the quality of the application code will immediately decrease, because we have a lot of duplicates. And in case there is a need to change the font in the future, we would have to change it in each file separately. We see that this is a job that we would like to avoid. Therefore, it makes sense to create a global CSS file that will define these basic styles for the entire application. In such a file you can successfully use CSS methodologies, not only in it.
CSS methodologies divide CSS code logically in a different way than components
The components divide the CSS code into fragments that relate to a specific place in the application. Not all methodologies divide in the same way. Let’s look at the OOCSS methodology – separates structure styles from skin styles, and also forces us to write container and its children styles independent from each other. These rules in no way duplicate the principles of the component approach. As part of the CSS code of the component, we can successfully apply the OOCSS methodology. But not only her! SMACSS and BEM methodologies will also work very well. Categories base, layout, state and theme from SMACSS are great for use in separate files in the component approach. The only difference would be to separate the module file into specific component files. BEM, in turn, is not only blocks, elements and modifiers – it is a specific approach to code, manifesting itself in the principles of naming, nesting, or using classes.
Summary
Each of us can create CSS methodologies. They are a set of rules (guideline) that a programmer must follow to make his code readable, reusable and easy to maintain. There is no single methodology that will be the best. Probably each of them could be implemented in a project. Although depending on the project, the level of difficulty of implementation may be different for them. There is a good chance that it will be easier for an existing application to implement OOCSS or BEM than SMACSS. It is worth keeping this in mind when deciding on a specific methodology. You shouldn’t be guided only by sympathy for one of them. One thing is certain – each of them gives us added value.