Modular CSS Approach : Best Practices

Read only if you care about Performance and Optimisation

First of all, let’s figure out the basic difference between Traditional/Modular CSS Models —

In Traditional or Waterfall Model, a single CSS file with .css extension have all the necessary styling rules for all elements. However, in Modular Model, styling rules for different elements exists in different files.

The very first question that arises is — Why do we need Modular CSS Approach, even if the Traditional/Waterfall CSS Model works for us? The Agile behaviour of Modular approach makes it stand out in the queue. In Modular approach, information exists in the form of small packets (i.e called components) which helps in easy collaboration and increases the scope of code reusability or scalability.

Traditional Model file structure scaffold —

Modular Model file structure scaffold —

From the above two Snapshots, it can be concluded that, the Modular CSS Model is easy to manage and code can be reused across different set of projects. Comparatively, it becomes quite clumsy in Traditional CSS Model to reuse the code, as code exists as a whole instead of being a set of components.

Apart from this, Modular CSS approach has a big advantage of Code Scalability and Adaptability as more and more custom components can be added in accordance with project requirements.

How it’s done?

A basic Modular Approach can be practised by placing the concurrent css files using “link href” in head section of the document one after the another one (Normally done whenever frameworks like Bootstrap/Zurb Foundation or GetMdl.io acts as a spine of the project). Or, making the use of ‘import’ CSS rule, as it’s shown below —

eh? eh? But, What about the HTTP Requests, if it’s done in such a gawky and shattered way? Let’s have a look at two individual use cases and figure it out, how exactly a browser responds to them —

CaseA

CaseA is performed with Modular CSS Approach and above three different files have been imported to “style.css” and the results with Chrome Browser Dev Console are snapped as shown below -

CaseA has following results when DOM was throttled with 50kb/s—

1. Requests = 7
2. DOMContentLoad Time = 583 ms
3. Load = 2.44 s

CaseB

CaseB is performed with Traditional CSS Approach and all of the css rules were placed inside “style.css” and the results with Chrome Browser Dev Console are snapped as shown below -

1. Requests = 4
2. DOMContentLoad Time = 544 ms
3. Load = 1.23 s

CaseA and CaseB Synopsis

CaseB had low number of HTTP Requests which helped the DOM tree to comparatively load faster than that of CaseA. But, on the other hand CaseA was a way scalable, flexible and agile in terms of code adaptability.

So, What’s the way to overcome this as we need both - the Code Scalability as well as high speed and low number of HTTP Server Requests?

Here comes in, the CSS PreProcessors like less.js or sass. Declaring and importing partials resolves the pain of HTTP Server Requests, as end of the day all of the partials are compiled into single CSS file which is loaded by the browser and on other hand code becomes usable and agile for a fully scalable dev phase.

It can be done using Less PreProcessor’s “import function”, Let’s have a look — how to do this?

1. Different files have been created for different components -

2. Each Component file with .less extension contains separate styling rules.

3. All partials are imported in main style.less file.

4. Finally, all partial .less files are compiled into single CSS file which is used by the browser in distro mode.

That’s how we can build CSS with Modular/Component approach for scalable and easy to manage code structure, which is agile enough to be reused across different projects — keeping you away from being WET (Writing Everything Twice); and deliver it to the browser with very low server requests too for a faster and optimised performance.

Now days different CSS Module Frameworks are available, few of them which are called Modulr.css and BlazeCSS are quite trending these days.