Rearchitect the new :cache feature of javascript_include_tag, similar to ToolbawksPacker

rubyonrails-core
1

I have done some work with the javascript and stylesheet helpers for ToolbawksPacker…

http://svn.toolbawks.com/toolbawks_packer/trunk/

Which more/less takes all executed javascript_include_tags and stylesheet_link_tag on any converged view (combines all partials and such) and builds a list of js and css files respectively and uses that to form a cache. In additon, it also minifies the JS using JSMin and uses a basic minification technique initiated by AssetPackager ( http://synthesis.sbecker.net/pages/asset_packager) and takes it to the next level.

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 javascript_include_tag and from what I have read, and it doesn’t combine all individual calls into a converged cache. Am I wrong? If so, would be great to find out.

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’).

Nathaniel.

2

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 javascript_include_tag and from what I have read, and it doesn't combine all 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 compression.

3

I guess he meant when you have more than one javascript_include_tag() calls. Like :

javascript_include_tag(:all, :cache => 'whatever')

Then in your partial :

<% content_for(:head) do %> <%= javascript_include_tag('some special js') %> <% 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 ++

4

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?

<%= javascript_include_tag(:defaults, ‘custom_code’, :cache => true) %>

Nathaniel.

5

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?

6

As a side note, from what I gather as well, is it possible to do something like this?

<%= javascript_include_tag(:defaults, 'custom_code', :cache => true) %>

Yes

7

Do you have other research that reduces the requirement for JSMin when using GZIP?

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 feature.

Keep this stuff in a plugin so users who want to use it can.

8

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.

9

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 certain valid javascript constructs that the minifier's mess up, it's 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.

10

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.