There's another way besides inlining and requirejs. In cases where you're doing server-side programming anyway, you can just have the server inject view-specific <link> elements pointing to individual CSS files as needed - augmenting the site's core CSS file. The downside is more requests to fetch those files, but after the first time you can take advantage of the browser's cache. As long as you keep the number of extra CSS files reasonable, this method costs almost nothing.
A variant of this is where you compile one CSS file from many view-specific ones beforehand. The advantage is it'll speed up things on the client side and the programming overhead is relatively small if you're using something to generate CSS anyway.
> In that case, it's because code reusability becomes a pita and you bloat your JS.
Does it? Last time I had a bigish web project, I was starting to inline everything (CSS and Javascript), and had my backend language deal with DRY. It even solved the problem CSS people use CSS generators for. As a rule, both CSS and javascrit suck for organizing content.
But then, I declared that project dead, and didn't wait to see the consequences of organizing things this way. So, somebody may have a much clear understanding about why that's wrong.
A variant of this is where you compile one CSS file from many view-specific ones beforehand. The advantage is it'll speed up things on the client side and the programming overhead is relatively small if you're using something to generate CSS anyway.