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.<p>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.<p>So, basically, if I have a component "example", with a view "list", then I can create a file in the default theme:<p><pre><code> themes/default/styles/components/example/list.css
</code></pre>
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.<p>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.<p>[1] <a href="http://wiki.appleseedproject.org/doku.php?id=developers" rel="nofollow">http://wiki.appleseedproject.org/doku.php?id=developers</a>
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.
I'm starting to like javascriptmvc, they've come up with some good practices for organizing code, combining/compressing it, and testing it.<p><a href="http://www.javascriptmvc.com/" rel="nofollow">http://www.javascriptmvc.com/</a>
I used to organize js binding based on the controller (<a href="https://github.com/pivotal/jelly" rel="nofollow">https://github.com/pivotal/jelly</a>), but found that it is better to base it on the template.<p>There are a few reasons:<p>1. It makes more conceptual sense. The javascript relates to html (which is generated by the template), not a controller action.<p>2. You will probably want to reuse templates across different controllers. Also partial templates can have reusable behavior.<p>3. It is easier to move between the associated javascript + template<p>4. Refactoring is easier, especially with html gotten via AJAX