CSS is incredibly mind-blowing. Mainly because all the layout and styling is controlled by a single file. If the style needs to change, switch out the options in the CSS file, and all of the headings update. Awesome! But as your content base grows in size, your approach to CSS may need to evolve to handle the strain.
Most journeys in web design start with writing vanilla CSS, then you move on to LESS, then SCSS, then Bulma, and right now, Tailwind CSS – and every shift delivers greater efficiency. Yet the bottom line remains, that with every new tool it’s still just a plain vanilla CSS file.
This post explores these CSS preprocessors and frameworks with some examples, and talks about how this can streamline your CSS development.
What is vanilla CSS?
Vanilla CSS is a term that describes essential CSS, without any added CSS preprocessors (more on these later) or development kits added. The biggest advantage of writing vanilla CSS is that no additional software is needed. You can quickly change a file, refresh your browser, and see the changes – even on your production server.
The big compromise with vanilla CSS, though, is that you need to be responsible for every single line of code – including every vendor prefix for specific definitions – for optimal browser support. While cross-browser support is getting better (and thankfully those IE6 days are long gone), at times vendor prefixing is still needed. But along with everything else, having that responsibility is too big a weight to bear, especially when there are tools that can help, such as CSS preprocessors.
CSS in web development
Whether you like writing vanilla CSS in a text editor, or using a preprocessor or framework to help you, the end result will be a CSS file. This file contains the instructions for the web browser on how to style and present your content – from colors and sizes through to layout and even mobile responsiveness.
Separating out the CSS into a file, as opposed to using attributes to style the HTML tags, saves time, because the CSS can target the same kind of element again and again without the designer having to repeat the style settings.
What are CSS preprocessors?
LESS, SASS, and SCSS are examples of CSS preprocessors. They are a form of scripting language that works to extend the CSS configured for a given website. Here’s the general order of events:
- You write CSS as you’d expect.
- You extend that CSS, and introduce syntax changes to make the CSS easier to write or read.
- The preprocessor then compiles the finished script into CSS that the browser can understand and apply to the HTML
CSS preprocessors and variables
One of the best features of using a CSS preprocessor is the introduction of variables. When your design is ready to be built, you’ll know what colors you need – such as a few shades of blue. You can create these as variables in your source, and reference the variable, not the hex RGB code.
If you find that one shade needs changing, you can then change a single variable value, re-process your code, and every reference to that shade of blue is updated and your finished CSS file is ready to go.
You can even use variables for things like specifying font family stacks, and also standardizing padding or margin values or responsive breakpoints to help create consistent changes to your interface.
CSS preprocessors and functions
Functions can also be written, and are a bit like variables, but on steroids. If you have specific rule sets that you often refer to, you could encapsulate these in a function. Anytime you need to use them in your code, just call the function (which can even accept input variables) and have the function’s CSS contents inserted at processing time.
CSS preprocessors and rule nesting
One of the best time-saving features of these languages is the nesting of rules. In vanilla CSS, if you need to access an H1 element within a wrapper within a section, your CSS needs to be:
section#content .wrapper h1 {...}And if you need to style your H2 too, you need to replace the whole rule definition yourself.
section#content .wrapper h1 {...}
section#content .wrapper h2 {...}And if the nesting structure changes in your markup, you’ve got a lot of code to go through. With a preprocessor language, you can nest the H1 and H2 definitions:
section#content {
.wrapper {
h1 {...}
h2 {...}
}
}NOTE: If your IDE has code formatting, your code can easily be formatted to create much more readable source code that can help you visually see the hierarchy, yet when processed will result in the same flat-level CSS code.
While you do need a compilation tool, SCSS saves time, so it’s worth the compilation tool. The ease of use of CodeKit, makes it fast and easy to get SCSS code up and running for easy compilation, auto-prefixing, and minification. Such a time saver!
LESS vs SASS vs SCSS
There are different CSS preprocessors available, so which one should you pick? The first thing to know before making a decision is all of these allow you to create and reuse variables, write callable functions, as well as nest your CSS. There are also additional tools involved:
- Use a command line utility, a build tool like Webpack or Laravel Mix, or get yourself an app to help manage your projects and configurations.
- CodeKit is for Mac only, so if you’re needing something for other operating systems, it’s a no-go.
- You could consider an app like Koala – and check out the LESS or SASS documentation for other suggestions.
These tools can also help you with auto-prefixing, generating source maps, and minification – valuable assets in any web developer’s toolbox.
CSS preprocessors: SASS and SCSS
Sass is available in a variety of languages, and you can start using it right away in your project by using a package like node-sass. SASS can combine with SCSS, as the syntax for SCSS works across different CSS preprocessors. The essentials of CSS preprocessors work well when both SCSS and SASS.
CSS preprocessors: LESS vs SASS and SCSS
Compared to SCSS and SASS, LESS has some additional CSS options available such as mixins. LESS is also written with JavaScript, which is the key difference between these CSS preprocessors. However, SASS makes use of loops and case distinctions, which may be the deciding factor between these preprocessors for your project.
NOTE: CSS frameworks are designed to be customized by taking advantage of the preprocessor benefits like variables, nesting, and functions already talked about in the preceding section.
What are CSS frameworks?
Preprocessors are one thing, but CSS frameworks such as Bootstrap and Bulma are fantastic to help you get a new site up and running fast. They contain the building blocks to help you build your site design with greater ease. For instance, you can access commonly used layout components from menus and navigation through to forms and media blocks.
Bulma vs Bootstrap
Bulma is a modern and clean flex-based CSS-only layout, meaning it’s a great choice for those wanting to use their own preferred flavor of JavaScript. Bootstrap, however, includes full interactivity with components and plugins using jQuery.
Bulma has the following features:
- A range of building blocks for building your own custom designs.
- Is customizable through SASS.
- Lets you choose the JavaScript implementation that works best for your team and project.
CSS framework troubleshooting
One concern with a ready-to-go framework can be their file size. While they can be tailored to suit your needs (and only include the components you actually need), you may also be importing lines upon lines of code that you’ll never use or take advantage of, but that’s still included in your final CSS.
This means your final CSS may not be as efficient as it could be.
Another concern is that many framework-built sites can start to look the same when developers decide to not customize or override the framework’s base stylings. While this can be great for quick prototypes, for a custom-designed website, it does mean you may need to spend time overriding the styles of components to make them look like your own. And if you’re spending that much time overriding every style (and at each breakpoint), it may have been a smarter choice to write your own SCSS from scratch, or use a utility-first CSS framework.
Tailwind CSS
Tailwind CSS is a superb utility-first CSS framework. Rather than having defined classes to create components, Tailwind CSS provides hundreds of classes that have a single function each – such as to change the padding, adjust a font size, or change a color.
If you’re using Bulma, or even LESS and SCSS, to create a button your HTML markup might look like this:
<button class="button">Button</button>;
It’s clean, clear, and simple, but also relies on a class called “button” that tells the browser how to style the element. Looking at the markup itself, it’s not clear what kind of style this button could have.
Using a utility-first framework like Tailwind CSS means your button HTML markup could look like this:
<button class="px-2 py-1 border-transparent font-medium rounded text-white bg-blue-500 hover:bg-blue-600 focus:outline-none focus:border-blue-700 focus:shadow-outline-blue active:bg-blue-700">
Button
</button>;
At first glance, you might just look and think that it’s an incredibly inefficient way to build a website – it’s honestly easy to mistake for an HTML style attribute. What’s the difference?
Tailwind brings with it an interface that has utility classes. For example the px-2 and py-2 class content means that button padding moves along the X and Y axis. Tailwind CSS can streamline development by keeping focus on the layout and build. You can make use of the utility classes added to the button element example rather than the semantics of CSS declarations (especially useful when some utility classes can apply multiple properties at once).
The button element is a great example because if you have five buttons on a page, you wouldn’t want to write that code five separate times, right? What happens if you have to change the color from “blue” to “green”?
There are two ways you could manage this, and it depends on your project:
- If you’re creating a web app in a component-based way (such as using Vue or React components) create a button component that has the styles built-in. That way you have a single point that captures your button styles. All you do is reuse your button component and boom, your button styles are all in place.
- Use the Tailwind CSS @apply option to define a class that is composed of the utility classes (or your own CSS too). Our button style could be defined as:
.button {
@apply px-2 py-1 border-transparent font-medium rounded text-white bg-blue-500;
&:hover {
@apply bg-blue-600;
}
&:focus {
@apply outline-none border-blue-700 shadow-outline-blue;
}
&:active {
@apply bg-blue-700;
}
}Then use a class of “button” to adopt all of those utilities.
Tailwind CSS efficiency
If you’re building an app that includes user-entered content – especially one that includes a rich text editor such as TinyMCE – you want to ensure that you don’t require your users to enter a dozen different utility class names just to style a button. This is where @apply can be incredibly useful. But for your app’s interface, using utility classes (especially with a component-based JavaScript library like Vue or React) makes Tailwind CSS shine.
CSS Tailwind and utility-first approaches
When starting out in a utility-first approach, you might want to carry over your love of CSS files and over-use @apply. When you notice recurring patterns – such as button styles – this is a suitable candidate for using @apply to help style buttons more easily. This is especially true within the context of developing an app that has user-editable content, because you want to avoid your users having to replicate all of these utility classes every time.
However, if you’re developing an app with a component-based frontend, like Vue or React, instead of using @apply and maintaining separate CSS blocks, the Tailwind CSS utilities are better stated directly in your reusable components, rather than needing a separate CSS file.
CSS Tailwind and size
While the default build of Tailwind CSS is rather heavy, it’s also designed this way. It offers hundreds of utilities that each do one little thing. But best practice would be to only use a small fraction of what’s available. Wouldn’t it be good if your CSS only included the utilities actually needed? Yep, it can do this!
When configuring your build step (for a tool like Webpack or Laravel Mix), make sure you also set up PostCSS to help control the file size. During the production build, your source code is reviewed – such as your JavaScript templates (Vue or React components) or framework templates like Blade or Twig files or even static HTML files. That means your final CSS is only made up of the Tailwind CSS utilities that are used in your source.
This process can dramatically reduce your final CSS size, especially if your markup is directly using the Tailwind CSS classes. While the HTML markup can become a little more verbose, it also becomes incredibly descriptive and meaningful during development, and takes advantage of reusing Tailwind CSS utilities throughout your code.
After actually building an interface using Tailwind CSS, you may find that it’s incredibly friendly, even if, in the beginning, it’s a bit of a puzzle.. It makes building, tweaking, and changing your interface feel intuitive. If you’ve never used a utility-first framework like Tailwind CSS, set aside some time to build something with it and see how it can fit in with your process.
CSS conclusion
If you like opening a text editor and writing vanilla CSS, that’s totally fine. But these are some tools that can help make your CSS coding more efficient.
Regardless of the approach you take, a solid understanding of CSS rules is needed and using a CSS preprocessor like LESS or SCSS is a great starting point for any project. There are some next steps you can take:
- A ready-to-go CSS framework like Bulma or Bootstrap can be incredibly time-saving
- A utility-first CSS framework like Tailwind CSS is also a fantastic approach
Just like choosing the best CMS, there’s no single answer that will work best for everyone. At the end of the day, CSS is still CSS – it’s just about how you get there that makes the difference.
But evolving your workflows can help keep your CSS coding more efficient. And while providing greater cross-browser support may seem an intimidating step initially, it may also be one that you find sustains your project into the future.
