I mildly disagree that coupling it to the controller makes the best sense. Maybe in MVC that isn't component structured, but even then, you'd probably want more granular control than that.
In Appleseed[1], I mapped CSS component views, and foundations. Foundations are layouts of components, and describe the whole page. Views describe a specific view of a component.
So, basically, if I have a component "example", with a view "list", then I can create a file in the default theme:
themes/default/styles/components/example/list.css
It will only get loaded into the <head> if the list view of the example component is loaded. I do similar things for the client-side Javascript.
It is good that people are working towards figuring out these patterns, though. The sooner we can move away from the wild west of spaghetti css and javascript, the better.
I would say a big disadvantage of doing it this way is you're serving up different CSS/JS files for each page. The approach in the article lets you separate your CSS out into files based on general "concerns" that make sense to your developers, while being able to use an asset packaging tool like Jammit (or even mod_pagespeed) to package them into one large CSS file that can then be cached by the browser, ISP proxies, and your CDN sitewide.
Not down with this as a Front End developer here. It's rare that I am able to work along side a developer to understand the structure of his components. Rather we code to a defined spec in HTML/JS/CSS and then throw over the wall for integration with development and back end. This could be near-shore, off-shore or internal - but rarely know before hand.
The gotcha here is that the selectors in that example SASS file are pretty inefficient. In that screenshot, you'll end up with a selector like ".main .site_box p .name", which the browser is going to parse from right to left. By putting everything behind a class namespace like that you force a potentially unnecessary class lookup on every selector. When you factor in how far nested SASS lets you get in combination with how much CSS a large webapp will require, it can have a large impact on page load speed.
But my gut feeling is that it doesn't matter. While I don't have any experimental data, I have to imagine this rendering penalty is in the noise of page/site performance. Asset packaging, gzip, using front end static server, etc are probably orders of magnitude more important for page rending speed than DOM traversal of CSS selectors.
That's why it's suggested you using Jammit (for Rails), or similar asset packager. Django has django-assetpackager. Or you can write your own pretty easily. Scoped selectors makes concatenating style-sheets safe.
If you have to sacrifice organization to gain performance, I think that's a sign you're doing something wrong. If number of requests is a concern, you should probably be doing asset packaging.
It's silly not to use a bundler with Rails (both for JS and CSS). That way you don't incur the performance hit from organizing project files by controller name.
In Appleseed[1], I mapped CSS component views, and foundations. Foundations are layouts of components, and describe the whole page. Views describe a specific view of a component.
So, basically, if I have a component "example", with a view "list", then I can create a file in the default theme:
It will only get loaded into the <head> if the list view of the example component is loaded. I do similar things for the client-side Javascript.It is good that people are working towards figuring out these patterns, though. The sooner we can move away from the wild west of spaghetti css and javascript, the better.
[1] http://wiki.appleseedproject.org/doku.php?id=developers