While the only truly valid way to style web applications and sites is through CSS, there are many different paths one can take to achieve a compiled CSS file.
While we typically write our CSS using the Sass pre-processor, there are other methods to creating CSS files that we should at the very least have a base-level knowledge of in the instances that a client has a method for creating CSS that they are strongly reliant on and don't want to change their internal processes.
A high level difference between popular pre- and post-processors is that pre-processors convert languages that extend CSS with their own syntax back into CSS files that a browser can parse. Post-processors start with normal CSS files that then are run through JavaScript plug-ins to transform them into production ready CSS.
For more information about pre- and post-processors, please read the following article Deconfusing pre- and post-processing, and review the documentation for some of the more popular processors at our disposal.
Pre-processors
Post-processors
How we generate our CSS is merely the first step on the road to an optimally styled project. Next we need to determine if a project calls for more thought than just simply compiling our CSS into a single file for inclusion on all pages of a site, or screen of an application. Can we be more purposeful in how we inject styling into our projects?
Cutting down on HTTP requests should be a top priority for website performance, however there may be times where it simply doesn't make sense to include all CSS into a single file.
For example, loading external fonts. It actually does us no favors to @import a font style sheet into our main CSS file. That import still counts as an HTTP request and actually is worse for performance than a typical <link> call, as @imports are required to be located at the top of CSS files. Being located at the top of the CSS file requires the browser to download the main CSS file, and then immediately have to download the external CSS file, blocking the rendering of the cascade while that external file is loaded and parsed.
Another example of when it may make sense to deviate from a single CSS file is when we need to optimize the loading of individual page styling over global styling. What I'm referring to here could be considered critical path CSS or Page-Critical CSS.
Critical Path CSS tools
The difference between Critical-Path and Page-Critical CSS is minor. The Critical-Path methodology is more focused on above-the-fold rendering, bringing those styles into the <head> of a document as inline styles. A Page-Critical direction would perform a very similar function, only it'd include all of unique styling required for that page, and not include those styles in the general CSS file at all. An example of when this might be practical is when a page requires a global style sheet for patterns that are reused across an entire website, but the page in question breaks the normal website layout and design patterns that define the main website as a whole, e.g. a one-off special promotion or product landing page.
For each of our projects we will need to determine the appropriate way to create our style sheets and include them that best benefits the requirements of the project and best practices. And as always, regardless of whatever decision we come to, we need to ensure that there is a clear reason and appropriate level of understanding with our client as to the direction we take.