http://synthesis.sbecker.net/pages/asset_packager) and takes it to the next level.
As it stands, the caching in ToolbawksPacker works on a config option that turns it on or off for the entire app, but in future if this isn’t in core by the time I get to it, I’ll look at a per execution of the toobawks_packer(‘cache_file_alias’).
Any chance we could see this as an enhanced technique to increase the core
functionality of this :cache feature? Right now it's on a single
individual calls into a converged cache. Am I wrong? If so, would be great
to find out.
In production mode, all files are combined into one leading to just 1
HTTP request for the cached js file. In development mode, they're
separately referenced to allow any changes to be instantly reflected.
JSMin and similar approaches are imo not worth it in a world of gzip
calls. Like :
Then in your partial :
<% content_for(:head) do %>
<% end %>
This will result in 2 js files. Which is what it should be imho.
Making it too complex doesn't seem to be worth it.
Plugin material ++
So my concern in the circumstances that lead to ToolbawksPacker was the need to have some JS files specifically for AJAX admin models and controllers isolated into plugin components, all plugins are converged into a massive list of js files (30+) which then, depending on what view you are in, are compressed into components for that layout.
After writing the original outline of what ToolbawksPacker does, it would be sweet to have it able to compartmentalize it.
So in such a case as mine, where I use the EXTJS library, Prototype, Scriptaculous, packaging them into a single JS file, then having any frequently updated JS files that I write myself, are in one or more depending if they are in the admin view state or regular user state of the application.
As a side note, from what I gather as well, is it possible to do something like this?
PS. JSmin compressed my JS by over 100k (I have a pretty AJAX intense app I am working on in admin mode). That being said, even with GZIP doing it’s thing, it’s 100k less that it needs to compress, therefor it seems that it does prove its value, at least in my circumstances. Most especially seeing as I comment quite a bit in my JS and provide detailed indentation (both of which are by default removed by JSMin).
Do you have other research that reduces the requirement for JSMin when using GZIP?
Do you have other research that reduces the requirement for JSMin when using
That 100k is a one time hit if you're sending your correct caching
headers. Spread over all the requests a user makes to your system
it's simply not worth the hassle. Definitely not for a core rails
Keep this stuff in a plugin so users who want to use it can.
I suppose… but reducing the site by any measure, especially what my findings reported (25%), it seems like it is valuable. Food for thought. It’s already a plugin, so I’m happy… just figured it might be worth sharing the insight and findings with the rest of those using the feature which will likely not find out about the plugin.
I suppose.. but reducing the site by any measure, especially what my
findings reported (25%), it seems like it is valuable. Food for thought.
That 25% becomes about 0.0000025% of your total bandwidth after the
user has clicked around inside your application. Given that there are
not worth the risk.
It's already a plugin, so I'm happy.. just figured it might be worth sharing
the insight and findings with the rest of those using the feature which will
likely not find out about the plugin.
If enough people find the plugin valuable it will get the traction it
deserves. If people aren't desperately searching for plugins to do
the minification, then we shouldn't be shipping that functionality.
I don't think bandwidth is the issue here. The issue is probably the
first impression a user gets from the site, and a slow-loading site
likely won't leave that good an impression.
I agree though that this is plugin material.