Rails core - Oct 2007 - Rearchitect the new :cache feature of javascript_include_tag, similar to ToolbawksPacker

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.

-- 
Nathaniel Steven Henry Brown
604-724-6624

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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 ++

On 10/5/07, DHH <david.heinemeier@gmail.com>
wrote:
>
> > 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.
>
>
> >
>

-- 
Cheers!
- Pratik
http://m.onkey.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On 10/5/07, DHH <david.heinemeier@gmail.com>
wrote:
>
>
> > 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.
>
>
> >
>

-- 
Nathaniel Steven Henry Brown
604-724-6624

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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?

On 10/5/07, DHH <david.heinemeier@gmail.com>
wrote:
>
>
> > 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.
>
>
> >
>

-- 
Nathaniel Steven Henry Brown
604-724-6624

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On 10/5/07, Michael Koziarski <michael@koziarski.com>
wrote:
>
>
> > 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.
>
> --
> Cheers
>
> Koz
>
> >
>

-- 
Nathaniel Steven Henry Brown
604-724-6624

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 10/6/07, Nathaniel Brown <nshb@inimit.com>
wrote:
> 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.


-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On L, 2007-10-06 at 12:52 +1300, Michael Koziarski
wrote:
> On 10/6/07, Nathaniel Brown <nshb@inimit.com> wrote:
> > 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.
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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---