

Best practices for JS and CSS organization - sghael
http://codefastdieyoung.com/2011/03/css-js-organization-best-practice/

======
michaelchisari
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.

[1] <http://wiki.appleseedproject.org/doku.php?id=developers>

~~~
jarin
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.

~~~
michaelchisari
_I would say a big disadvantage of doing it this way is you're serving up
different CSS/JS files for each page._

You don't have to, though. You can put everything into a single global css
file, and be done with it.

And I haven't implemented it, but I can immediately see easy ways to package
it all up into single files that can be easily cached.

It's easier to consolidate the files programmatically after they've been
logically separated, than to logically separate out of a monolithic location.

------
cubtastic71
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.

~~~
dfischer
As a front-end developer here, how do you organize your code?

------
Hovertruck
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.

~~~
joevandyk
_can have a large impact on page load speed_

any data on this?

~~~
guywithabike
It has a very minor impact:

[http://www.stevesouders.com/blog/2009/06/18/simplifying-
css-...](http://www.stevesouders.com/blog/2009/06/18/simplifying-css-
selectors/) (Steve is a pretty authoritative source for web optimization.)

tl;dr: avoid selectors that end in * and you should be fine.

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

~~~
phlid909
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.

------
stratospark
I'm starting to like javascriptmvc, they've come up with some good practices
for organizing code, combining/compressing it, and testing it.

<http://www.javascriptmvc.com/>

------
mwsherman
Great minds: <http://mvccss.codeplex.com/>

------
binspace
I used to organize js binding based on the controller
(<https://github.com/pivotal/jelly>), but found that it is better to base it
on the template.

There are a few reasons:

1\. It makes more conceptual sense. The javascript relates to html (which is
generated by the template), not a controller action.

2\. You will probably want to reuse templates across different controllers.
Also partial templates can have reusable behavior.

3\. It is easier to move between the associated javascript + template

4\. Refactoring is easier, especially with html gotten via AJAX

