This project is archived and is in readonly mode.
Minify packaged javascript libraries
Reported by Nathaniel Bibler | January 20th, 2009 @ 08:38 PM | in 2.x
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?
Comments and changes to this ticket
-
Nathaniel Bibler January 21st, 2009 @ 05:20 AM
- 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.
-
Jacek Becela January 21st, 2009 @ 08:21 AM
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.
-
Nathaniel Bibler January 21st, 2009 @ 04:13 PM
Fair enough. I was chatting with someone in
#rails-contriblast 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.
-
Jacek Becela January 21st, 2009 @ 10:07 PM
Ability to read code is in no way excuse for not having solid API docs, I prefer that too ;)
-
DHH February 5th, 2009 @ 08:12 PM
- State changed from “new” to “wontfix”
Most people use gzip as well, which pretty much nullifies the benefits of minifying.
-
Nathaniel Bibler February 5th, 2009 @ 08:30 PM
True. Thanks for the consideration and feedback, guys. :)
-
Ryan Bigg October 14th, 2010 @ 04:51 AM
- Tag cleared.
- Importance changed from “” to “Low”
Automatic cleanup of spam.
-
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Jeremy Kemper
Nathaniel Bibler
Ryan Bigg