Best practices for JS and CSS organization (opens in new tab)

(codefastdieyoung.com)

54 pointssghael15y ago19 comments

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

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

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

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

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

dfischer15y ago

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

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

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

joevandyk15y ago

can have a large impact on page load speed

any data on this?

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

plainOldText15y ago

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

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

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

jpeterson15y ago

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

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

isfinite15y ago

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

stratospark15y 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/

mwsherman15y ago

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

binspace15y 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

j / k navigate · click thread line to collapse

19 comments

michaelchisari15y ago

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

jarin15y ago

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

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

cubtastic7115y ago

dfischer15y ago

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

Hovertruck15y ago

sghaelOP15y ago

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

joevandyk15y ago

can have a large impact on page load speed

any data on this?

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

plainOldText15y ago

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

phlid90915y ago

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

jpeterson15y ago

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

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

isfinite15y ago

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

stratospark15y 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/

mwsherman15y ago

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

binspace15y 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

j / k navigate · click thread line to collapse