Re: [RFE] packed JS in DEPLOYMENT mode.
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] - 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] smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFE] packed JS in DEPLOYMENT mode.
What do you mean by included resources ? By default every js and css under src/main/resources, src/main/webapp, src/main/js are minified. (using the resources option is for exceptionnal case) Contact me privatly for questions about the plugin (not related to wicket). Alex Objelean wrote: David, what is the best practice to specify the order of included resources? Thank you! David Bernard-2 wrote: You could aggregate every type of resources. Alex Objelean wrote: Very interesting. Would be nice to have also aggregate css. Regards, Alex. David Bernard-2 wrote: If you want you could use the yuicompressor-maven-plugin to minified (more than just strip whitespace) at build time. http://alchim.sf.net/yuicompressor-maven-plugin Other features: * aggregate js * minified css So you could test/run with minified in development and/or deployment mode Disclamer, I'm the author of the plugin, but not of the compressor. Regards - 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]
Re: [RFE] packed JS in DEPLOYMENT mode.
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 smime.p7s Description: S/MIME Cryptographic Signature
[RFE] packed JS in DEPLOYMENT mode.
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. Any thoughts? Alex -- View this message in context: http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14022953 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] packed JS in DEPLOYMENT mode.
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#a14023353 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [RFE] packed JS in DEPLOYMENT mode.
Wicket already strips whitespace and comments in deployment mode. Using another tool to pack the javascript doesn't gives much advantage and introduces another dependency. -Matej On Nov 29, 2007 11:17 AM, Alex Objelean [EMAIL PROTECTED] 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. Any thoughts? Alex -- View this message in context: http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14022953 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]
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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]
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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]
Re: [RFE] packed JS in DEPLOYMENT mode.
I agree with you. It is quite hard to maintain two files for every script. I
was just thinking out loud :)..
Alex.
Matej Knopp-2 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(ca?'':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]
--
View this message in context:
http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14025500
Sent from the Wicket - User mailing list archive at Nabble.com
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [RFE] packed JS in DEPLOYMENT mode.
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(ca?'':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
Re: [RFE] packed JS in DEPLOYMENT mode.
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFE] packed JS in DEPLOYMENT mode.
If you want you could use the yuicompressor-maven-plugin to minified (more than just strip whitespace) at build time. http://alchim.sf.net/yuicompressor-maven-plugin Other features: * aggregate js * minified css So you could test/run with minified in development and/or deployment mode Disclamer, I'm the author of the plugin, but not of the compressor. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] packed JS in DEPLOYMENT mode.
Very interesting. Would be nice to have also aggregate css. Regards, Alex. David Bernard-2 wrote: If you want you could use the yuicompressor-maven-plugin to minified (more than just strip whitespace) at build time. http://alchim.sf.net/yuicompressor-maven-plugin Other features: * aggregate js * minified css So you could test/run with minified in development and/or deployment mode Disclamer, I'm the author of the plugin, but not of the compressor. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14027441 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] packed JS in DEPLOYMENT mode.
You could aggregate every type of resources. Alex Objelean wrote: Very interesting. Would be nice to have also aggregate css. Regards, Alex. David Bernard-2 wrote: If you want you could use the yuicompressor-maven-plugin to minified (more than just strip whitespace) at build time. http://alchim.sf.net/yuicompressor-maven-plugin Other features: * aggregate js * minified css So you could test/run with minified in development and/or deployment mode Disclamer, I'm the author of the plugin, but not of the compressor. Regards - 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]
Re: [RFE] packed JS in DEPLOYMENT mode.
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] - 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]
