25

When writing javascript for a specific page in a site, when do you want to turn the javascript into a function and include it in application.js?

I've seen suggestions about doing this (and minifying or gzip-ing) to minimize HTTP requests. That makes sense, but what about maintainability? If I have js code specific to one view, it seems like more work to look into a potentially massive application.js. That code could be embedded into that view or put in its own .js (or .js.erb or .rjs) file in that view folder.

I've seen another suggestion that Rails automatically merges all javascript into one file. Is this true?

TLDR: how much or how little should a developer worry about optimization when writing javascript?

Community
  • 1
  • 1
Eric Hu
  • 18,048
  • 9
  • 51
  • 67

1 Answers1

48

As I haven't seen an answer in about a month, I'll answer this question to the best of my current knowledge.

Rails 3.1 (currently at release candidate 4) introduces sprockets, which will compile all javascript in a rails project into one file. It even comes with tools to minify and compress javascript so that it's all delivered to the client at once.

Related to sprockets is the Rails 3.1 asset pipeline. As I understand, it's a folder hierarchy/abstraction. Javascripts can go into 3 folders:

/apps/assets/javscripts/
Javascript files specific to the application, including application.js. This should only contain the manifest of javascript files you want to include in your project. The rails new tool will generate this file and include jquery in the manifest.

/lib/assets/javascripts/
Javascript files written by the developer that are more general purpose. (My impression is that this would be for javascript libraries you develop to drop into multiple applications)

/vendor/assets/javascripts/
Third party javascript files (i.e. JQuery, Modernizr)

All files in these folders will appear to the client inside /assets/, abstracting out the server side file paths. I assume this is meant to help the developer organize javascript files.

To answer my own question

  • Put javascript functions into separate files, group them logically. My test app indicated that subfolders within .../assets/javascripts/ are ok if and only if the subfolder path is included in the manifest.
    • I.E. putting //= subfolder/js_file in the manifest will work. Putting //= js_file will not if js_file is inside .../javascripts/subfolder/
    • DHH mentions a "rule of 13" in his talk (linked below). If the number of javascripts in a folder exceeds 13, it starts to look messy and unmanageable. This would be a good time to group javascript files into subfolders.
  • Use the built in Rails 3.1 minifier and compressor (or install a preferred gem)
  • Refactor javascript code from time to time. Move functions to /lib/assets/javascripts/ over time. (The goal is to eventually recognize when you want to write general purpose javascript functions as opposed to application-specific ones and eliminate this refactor step)

More Resources

a blog post covering all changes in Rails 3.1
DHH's talk on Rails 3.1 changes, May 16 2011 (~1 hr)

Eric Hu
  • 18,048
  • 9
  • 51
  • 67
  • This is super helpful, thanks! I'm still curious, though, about trying to create separate javascript downloads on the client side. I don't want every JS file on my site to get clumped into one. For most of my site I want one set of JS files, and for another part I have a 100% orthogonal set of files. This is proving to be challenging. – drewww Jun 05 '13 at 22:42
  • @drewww I don't have an answer for that since I don't know all the details. It could be a premature optimization since the JS files are delivered once to a user. On the other hand, some single page apps can get pretty large, in which case these different parts might justify splitting the app into multiple apps if they're responsibilities are sufficiently orthogonal. – Eric Hu Jun 10 '13 at 16:12
  • Yeah, ultimately decided it was a premature optimization. It felt like a burden because the vast majority of users won't need the backbone/JS-heavy part of the experience (think something like an admin experience), but it's really not that big right now. Will deal with it later when load times are really the most salient issue. Thanks for your help! – drewww Jun 12 '13 at 13:35