Rails 3.1: why ".css.scss" and ".js.coffee" extensions?

rubyonrails-core
1

Rails 3.1 generators* create stubs for “.css.scss” and “.js.coffee” files in “app/assets/” directory.

Why the double extension? It made sense in view templates (e.g. “index.html.erb”) because of the request formats and the fact that some template engines can render multiple types of output, not just html.

Assets don’t have request formats nor can Sass and CoffeeScript render anything but CSS and JavaScript.

I understand this might have been an attempt to preserve the current “naming convention”, but is it worth preserving this “convention” now that it lost its meaning?

2

I think these extensions are just the hints to call a chain of template renderers under Sprockets & Tilt. So .js.coffee.erb would first render with ERB, then CoffeeScript. I read thru the Sprockets & Tilt source and you can just keep tacking these things on. Pretty clever in my book.

About the only thing I have run into that is not an issue with either of these libraries is getting my editor to focus on the proper language scope. For instance, if I were editing a a foo.css.scss.erb I would want my editor to not use my normal erb language theme but instead .scss. This is easily solvable on my own end tho.

  • Ken
3

I think these extensions are just the hints to call a chain of template renderers under Sprockets & Tilt. So .js.coffee.erb would first render with ERB, then CoffeeScript. I read thru the Sprockets & Tilt source and you can just keep tacking these things on. Pretty clever in my book.

Yep : DHH showed this exact feature last week at RailsConf.

4

That’s pretty rad, but it doesn’t explain what are “.js” and “.css” hints for.

I’m pretty sure that the whole Sprockets feature stack would work even without those. I’m wondering about the rationale of making this the default recommended style (by making generators create them).

5

They get served in /assets, and so you wouldn’t be able to tell the difference between the end /assets/application.js and /assets/application.css

This doesn’t mean the intermediate ones couldn’t have them stripped, but whatever.

6

That's pretty rad, but it doesn't explain what are ".js" and ".css" hints for.

I'm pretty sure that the whole Sprockets feature stack would work even without those. I'm wondering about the rationale of making this the default recommended style (by making generators create them).

Feels pretty consistent to me : *.html.erb, *.js.erb *.css.erb

7

Got an official answer: https://twitter.com/#!/rails/status/73140918739406848

It comes down to two reasons: keeping the convention from regular views, and exposing the feature of Sprockets where asset processors can be stacked (also discussed on this thread).