Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Minify packaged javascript libraries

#1786

The packaged JavaScript libraries - Prototype and script.aculo.us - which are currently bundled with Rails are provided in their full, uncompressed, "development" versions:

  • controls.js (34716B)
  • dragdrop.js (31103B)
  • effects.js (38675B)
  • prototype.js (129738B)

(4 JS files weighing in at 234kB, as of Rails 2.2.2, Prototype 1.6.0.3)

Using the freely available Yahoo! YUI Compressor with its default settings, the same 4 files become:

  • controls.js (21542B)
  • dragdrop.js (19256B)
  • effects.js (24677B)
  • prototype.js (74956B)

(4 JS files weighing in at 140kB)

That's about a 40% reduction in file size with supposedly no changes to functionality.

I realize that applications should probably ultimately be moving toward hosted libraries (using Google AJAX Libraries API, for example), but as long as the Rails framework is bundling libraries, shouldn't we try to lessen their impact as much as possible? Further, I'd argue that the uncompressed versions of those libraries are not necessary to provide with the Rails framework at all, as we HIGHLY encourage people to not modify those files directly. In fact, each new release of Rails seems to overwrite those files with the latest JS framework version, so we instead endorse using a application.js to add any custom functionality that may be required.

This seems like a relatively simple change that has a large, positive application performance impact.

Thoughts?

Reported by Nathaniel Bibler · January 20th, 2009 @ 08:38 PM

State: wontfix
Milestone: 2.x
Assigned to: nobody
Importance: Low

Activity

  1. Nathaniel Bibler
    Nathaniel Bibler
    • Tag changed from javascript, performance, prototype, scriptaculous to javascript, patch, performance, prototype, scriptaculous

    Here is a sample patch with the libraries minified using the default YUI Compressor settings, but retaining the file comment headers.

    January 21st, 2009 @ 05:20 AM

  2. Jacek Becela
    Jacek Becela

    On the other side:

    "Minifying" is not the right solution for bandwidth issues. In my opinion it is responsibility of server that is hosting the app to compress its output.

    Also the reduction of 40% takes place only in these javascripts, so overall reduction (including html/css/images/etc.) is far worse.

    I'd like to be able to just read this code. It saves me sometimes.

    January 21st, 2009 @ 08:21 AM

  3. Nathaniel Bibler
    Nathaniel Bibler

    Fair enough. I was chatting with someone in #rails-contrib last night who had the same thoughts. I guess I just rely more heavily on the API documentation than reading the actual source and assume that the packaged libraries are working and bug-free. :)

    I guess the better solution would be to encourage people to tie in the YUI Compressor (or some other solution) with a capistrano deployment or continue to push the Google AJAX API.

    Thanks for the feedback on it.

    January 21st, 2009 @ 04:13 PM

  4. Jacek Becela
    Jacek Becela

    Ability to read code is in no way excuse for not having solid API docs, I prefer that too ;)

    January 21st, 2009 @ 10:07 PM

  5. DHH
    DHH
    • State changed from new to wontfix

    Most people use gzip as well, which pretty much nullifies the benefits of minifying.

    February 5th, 2009 @ 08:12 PM

  6. Nathaniel Bibler
    Nathaniel Bibler

    True. Thanks for the consideration and feedback, guys. :)

    February 5th, 2009 @ 08:30 PM

  7. Ryan Bigg
    Ryan Bigg
    • Tag cleared.
    • Importance changed from to Low

    Automatic cleanup of spam.

    October 14th, 2010 @ 04:51 AM

  8. Jeff Kreeftmeijer
  9. bingbing