Best practices for JS and CSS organization

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 &#60;head&#62; 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.

With so many css and js files you increase the number of requests to the server. It's not optimal.

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>

Great minds: <a href="http://mvccss.codeplex.com/" rel="nofollow">http://mvccss.codeplex.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