We do also serve javascript gzipped, so there is no reason for using
mod_gzip either.
-Matej
On Nov 29, 2007 1:48 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> I'm with Matej on this one.
>
> 2 files to maintain, extra code logic in Wicket itself to maintain,
> extra complexity, with no real gain. Wicket markup can already be
> "minimified" (see Matej's other mail), and I really think using
> something like mod_gzip is a much better option: separation of concerns
> and you get compression on other stuff as well.
>
> Regards,
> Sebastiaan
>
>
>
> Matej Knopp wrote:
> > But that would mean maintaining two files for every script. Which
> > means at least a compilation time dependency. And I still don't see
> > good reason for this.
> >
> > -Matej
> >
> > On Nov 29, 2007 1:26 PM, Alex Objelean <[EMAIL PROTECTED]> wrote:
> >> Sebastiaan, Matej, I think you get me wrong.
> >> I do not suggest to minify the js files in runtime. What I suggest, is to
> >> have both, for instance: wicket-ajax.js & wicket-ajax.pack.js, in the
> >> distributed jar. And include the wicket related js this way:
> >>
> >> if (Application.DEVELOPMENT
> >> .equalsIgnoreCase(Application.get().getConfigurationType())) {
> >> add(HeaderContributor.forJavaScript(new ResourceReference(
> >> AbstractDefaultAjaxBehavior.class, "wicket-ajax.pack.js")));
> >> } else {
> >> add(HeaderContributor.forJavaScript(new ResourceReference(
> >> AbstractDefaultAjaxBehavior.class, "wicket-ajax.js")));
> >> }
> >>
> >> Alex.
> >>
> >>
> >>
> >> Sebastiaan van Erk wrote:
> >>> I'm talking about packers (like the jQuery packed version):
> >>>
> >>> What I see in jQuery.pack.js:
> >>>
> >>> eval(function(p,a,c,k,e,r){e=function(c){return(c<a?'':e(parseInt(c/a)))+
> >>> ((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,
> >>> String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return
> >>> r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new
> >>> RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('(G(){9(1m E!="W")H w=E;H
> >>> E=18.15=G(a,b){I 6 7u E?6.5N(a,b):1u E(a,b)};9(1m $!="W")H D=$;18.$=E;H
> >>> u=/^[^<]*(<(.|\\s)+>)[^>]*$|^#(\\w+)
> >>>
> >>> etc... etc...
> >>>
> >>> This is run every time the document is loaded (onload) which is quite a
> >>> hit on client side performance.
> >>>
> >>> I guess removing extra whitespace or shortening variable names could
> >>> help some (minimizer), but I think it's pretty much useless in most
> >>> cases. I think a better options is installing something like mod_gzip
> >>> which can also gzip outputted html.
> >>>
> >>> In the jQuery case:
> >>>
> >>> jQuery is 79 kb plain unzipped.
> >>> jQuery is 46 kb minimized unzipped.
> >>> jQuery is 26 kb plain gzipped.
> >>> jQuery is 13 kb minimized gzipped.
> >>>
> >>> The difference in this case is 33 kb a single time when using unzipped
> >>> (because it's cached after load), and 13 kb a single time when using
> >>> mod_gzip. If your site has any number of images they're going to make
> >>> any gains you're going to get out of this quite irrelevant IMHO.
> >>>
> >>> Personally I think it's a waste of time and the extra complexity of
> >>> packed/nonpacked in deployment/development mode is seriously not worth
> >>> it. Furthermore the core developers only have so much time, and I think
> >>> in that respect it's also a waste of their time if they had to support
> >>> this.
> >>>
> >>> Regards,
> >>> Sebastiaan
> >>>
> >>>
> >>>
> >>> Alex Objelean wrote:
> >>>> What do you mean by "unpacked"?
> >>>> "packing" = "minified", using Rhino Shrinksafe of JSMin or Yahoo tool for
> >>>> this purpose.
> >>>> It is indeed does not result in a performance boost, but it is still an
> >>>> improvement.
> >>>>
> >>>>
> >>>> Sebastiaan van Erk wrote:
> >>>>> I don't really understand the desire to pack js.
> >>>>>
> >>>>> For who do you want to reduce the overall traffic? The client, or the
> >>>>> hoster?
> >>>>>
> >>>>> I experimented with the packed js, but in general I hardly notice the
> >>>>> overhead for some js (the sum of the size of images is often bigger than
> >>>>> the sum of all the js). Furthermore, the js is static: it almost never
> >>>>> changes, so the it is downloaded only once! Also, if the js is reused
> >>>>> accross pages, then it's only downloaded once on one page! Thus you are
> >>>>> optimizing for the very first pageload.
> >>>>>
> >>>>> However, the js has to be unpacked by the client EVERY SINGLE PAGE VIEW.
> >>>>> When using the packed jQuery lib, I really NOTICED this a lot. It was
> >>>>> VERY irritating (couple 100 ms delay every time I view ANY page on my
> >>>>> site).
> >>>>>
> >>>>> Regards,
> >>>>> Sebastiaan
> >>>>>
> >>>>>
> >>>>> Alex Objelean wrote:
> >>>>>> It would be nice to have 2 versions of each js: original & packed.
> >>>>>> For instance: wicket-ajax.js & wicket-ajax.pack.js
> >>>>>> Also to use the packed version in DEPLOYMENT model. This is applicable
> >>>>>> to
> >>>>>> other js from the wicket-core & wicket-extensions. The idea is to
> >>>>>> reduce
> >>>>>> the
> >>>>>> overall traffic.
> >>>>>>
> >>>>>> Any thoughts?
> >>>>>>
> >>>>>> Alex
> >>>>>
> >>>
> >>>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14024597
> >>
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
