My approach to responsive web

Over the last few weeks I’ve been working on a large responsive site using Sass.

Starting working on a responsive site as opposed to a mobile app using something like Ionic, means a lot more thought has to go into how you’ll manage and set out your sass files and use media queries.
When I worked on other responsive sites I always created a separate ‘responsive’ sass or less file (I’m mainly using Sass now, but did use Less a while ago), which contained all my media queries.
I would then load that as the last Sass/Less file, so it would pick up any styles that I wanted to amend in my media queries. This was fine, but as the site grew and there was more and more in my media queries, the single Sass/Less file became huge.
So now I’ve changed my approach, what I’ve been doing to separating my Sass files into components, so I’ll have a Sass file for each page, one for the header, one for the footer section, one for fonts and one for constant variables. I took this approach after reading this great article in SitePoint (http://www.sitepoint.com/architecture-sass-project/).
Now instead of having this single ‘responsive’ file, I’m putting all my media queries in each separate Sass file. So for example in my header Sass file I may have to site title. Within that css class I’ll have the media query for each screen size.
One extra benefit this has, besides getting rid of the massive ‘responsive’ Sass file. Is that when you work as part of a team, with other developers who are not focused on the front-end, if they are .Net developers who work a bit with the front-end work, but leave it mainly to the front-end developer. Which is how I’m working now.
If they need to amend a style that is in a media query they will be able to find the correct style a lot easier. This removes the problem where another developer may want to add a new style, and they are not sure where to add the style so they add it to a new Sass file. With this more modularised approach if they want to amend a media query based style they know where to go. Then as the main front-end developer I can manage the Sass files a lot easier.
This approach may have problems, but I’m going to give it a go on the project I’m working on.