Vinay Raghu is a UI/UX developer passionate about experimenting with the latest frontend technologies. He is an avid open source contributor and loves meetup groups. You can learn more about him at viii.in.

Vinay's articles

  1. A Look at Different Sass Architectures

    As the size and complexity of a project grows, you require some sort of logic to structure your Sass files. It helps to follow some agreed upon guidelines for creating files and folders when working in large teams and projects. Below is a review of some of the techniques in use today.

    Bootstrap-sass

    Bootstrap’s intention is to be a UI library for web developers to quickly get off the ground. It is logical for them to group all variables in a single file and keep all the mixin logic hidden. Their Sass architecture mimics this idea. Each component gets its own Sass file and there’s a ./_variables.scss file, which allows you to control all the variables involved with your project.

    Bootstrap’s Sass architecture is unique in how it lays out its mixins. There’s a ./_mixins.scss file. This file imports all files from a mixins folder, which contains a separate file for every mixin used. Although button styles are defined in ./_buttons.scss, the mixins used for it are imported from ./_mixins.scss. This, in turn, imports the button mixins frommixins/_buttons.scss. Yo Dawg!

    In addition to component-level mixins, the mixin folder also contains global mixins such as mixins/_border-radius.scss and mixins/_responsive-visibility.scss. Although bootstrap’s mixins are not overly complex, this architecture is better suited for a project where the mixins are really complex and require that they be broken down into smaller bits. Or in cases where you want to keep that logic hidden from visual styles of components. In conclusion, this architecture works best for Bootstrap but might not work for your sass project.

    Here’s how the folder structure looks: