As Ruby developers, most of us spend our time building websites, and whether we like it or not we have to write and maintain a lot of
Rails tells us a lot about how to structure our back-end code, but very little about how to structure our front-end code. Beyond providing a few simple helper methods it's more or less silent on the subject.
Just because Rails doesn't make these decisions for us doesn't mean they don't need to be made.
Hooray for Rails 3!
We don't have to use Prototype, but can replace it with the best framework for this particular team or project.
Eventually, the helpers aren't enough
Although the helpers are now very good, they still only provide very basic functionality.
Rails to the rescue
We've talked about adding classes to the body, and setting custom HTTP headers.
Why not roll all of this into some handy Rails helpers?
@js_features ||= 
@js_features << feature.to_s.downcase if request and request.xhr?
header = @js_features.uniq.join(' ')
Small, carefully named files are easier to maintain.
Make use of CSS's specificity rules: you can override what went before by being more specific.
Serving front-end code from Rails
Breaking down our front-end code into small, manageable files is a good thing, but making lots of HTTP requests is inefficient.
The future's bright
public is for designers, those messy kids, app is for the high-level programmer stuff that
we care about. That's not really a good way of going about it … and we've been forgetting about stylesheets and