Didn't know that; that's nice. :-) Learn something new every day.

Do you also serve the HTML gzipped?

Regards,
Sebastiaan

Matej Knopp wrote:
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]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to