Best practices for JS and CSS organization

Best practices for JS and CSS organization(codefastdieyoung.com)

54 points by sghael 15 years ago | 19 comments

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 15 years ago | |

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 15 years ago | | |

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.

joevandyk 15 years ago | |

I agree. If you change the names of your controllers, or need the same css in a different controller, you have to make css changes.

This can be a pain. Better to decouple your css from the backend.

cubtastic71 15 years ago |

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 15 years ago | |

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

Hovertruck 15 years ago |

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.

sghael 15 years ago | |

this is an interesting point (I've up-voted you).

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.

joevandyk 15 years ago | |

can have a large impact on page load speed

any data on this?

guywithabike 15 years ago | | |

It has a very minor impact:

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

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

plainOldText 15 years ago |

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

phlid909 15 years ago | |

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.

sorghum 15 years ago | |

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.

jpeterson 15 years ago | |

This is pretty easy to solve after the fact by combining assets.

Timmy_C 15 years ago | |

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.

isfinite 15 years ago | |

that's what a build process is for. organization during dev / optimization during production

stratospark 15 years ago |

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 15 years ago |

Great minds: http://mvccss.codeplex.com/

binspace 15 years ago |

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