And, I should mention, in my mind the ideal JS structure is able to accomodate both cases. Download the code for most of your pages as part of the normal bundle, only executing the correct page-specific calls. Then on special pages, download the extra bits that were too big to reasonably throw into the sitewide bundle.
On Tue, Apr 3, 2012 at 10:30 AM, Marc Leglise <[email protected]> wrote: > James, that approach works for many cases, but not all the time. Say you > have one action in particular that is the only page that needs to load a > big dependency library? Especially if you're targeting mobile, with > reduced caching for larger files, there are cases where you want to have a > few pieces that only load on the appropriate pages. > > > On Tue, Apr 3, 2012 at 10:27 AM, James Miller <[email protected]> wrote: > >> What's wrong with loading all JS on every page? That was the main point >> of the mailing list discussion -- one minified, gzipped file that is >> fetched once by the browser but only inits items relevant to the current >> page. >> >> On Tuesday, April 3, 2012 at 10:23 AM, Marc Leglise wrote: >> >> Raf, if you want to handle asset pipeline in general, I could talk about >> a pattern we developed to manage page-specific (controller and action >> specific) JS triggers, without loading ALL the JS on every page. Anyone >> interested in that for this week, or save it for next month? >> >> -Marc >> >> >> On Tue, Apr 3, 2012 at 10:05 AM, Patrick Crowley <[email protected]>wrote: >> >> Let's do the asset pipeline. That's still tripping up a lot of people. >> >> -- Patrick >> >> >> On Apr 3, 2012, at 9:34 am, Ylan Segal wrote: >> >> > On Apr 3, 2012, at 8:05 AM, Rafael Cardoso wrote: >> > >> >> Hey, I can do the asset pipeline and twitter bootstrap. Used both. >> Also kaminari with bootstrap pagination. Both of those are short topics. >> > >> > >> > I would be interested in that... I am looking into all of those for new >> project. >> > >> > -- >> > Ylan >> > >> > -- >> > SD Ruby mailing list >> > [email protected] >> > http://groups.google.com/group/sdruby >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> > > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
