You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> on 2007/10/01 01:54:50 UTC
[jira] Created: (TAPESTRY-1792) JavaScript libraries should be
automatically packed/minimalized
JavaScript libraries should be automatically packed/minimalized
---------------------------------------------------------------
Key: TAPESTRY-1792
URL: https://issues.apache.org/jira/browse/TAPESTRY-1792
Project: Tapestry
Issue Type: New Feature
Components: tapestry-core
Affects Versions: 5.0.5
Reporter: Howard M. Lewis Ship
Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Martin Reurings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659433#action_12659433 ]
Martin Reurings commented on TAP5-73:
-------------------------------------
A built-in feature set such as this has the potential of a negative effect on real high-performance websites:
- Packing Javascripts may cause scripts that could have been cached client-side to get reloaded numerous times.
- Packing Javascripts may cause unneeded Javascript to get sent (and parsed) numerous times
- If T5 stays responsible for supplying what are essentially 'static' files these cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
- Packed/Compressed Javascripts are almost impossible to debug properly.
I'm quite certainly missing some more negative side-effects, but these feel likel enough to make my point. Features like these are great to have in a framework, but must be disabled by default, in my humble opinion. Also, I have to agree with some of the previous posters in stating, this should be fixed at build-time not take CPU and memory at run-time.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1792) JavaScript libraries should be
automatically packed/minimalized
Posted by "Jérôme BERNARD (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531422 ]
Jérôme BERNARD commented on TAPESTRY-1792:
------------------------------------------
This page might help:
http://getahead.org/blog/joe/2005/07/22/javascript_who_wants_a_compression_utility.html
You've got JSMin (http://www.crockford.com/javascript/jsmin.html -- AS IS licence) Java translation at:
http://inconspicuous.org/projects/jsmin/JSMin.java
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAPESTRY-1792
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1792
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Issue Comment Edited: (TAP5-73) JavaScript libraries should
be automatically packed/minimalized
Posted by "Jordi Hernandez Sellés (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660817#action_12660817 ]
jordihs edited comment on TAP5-73 at 1/5/09 9:00 AM:
--------------------------------------------------------------------
I'd love to see Jawr used by Tapestry, so I thought you might want more info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This means that you don't need to force users to learn how to use any new tool, but rather you can just use it behind the scenes.
There is some specific documentation on the subject at https://jawr.dev.java.net/integration/augmenter.html. You can get a general idea there, but integration possibilities go beyond what is explained there. For instance, the tag library delegates in tag-agnostic renderers. I made a JSF tag library out of these and each tag is almost a one-liner. I'm willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not modified) header and empty response body when if-modified-since or if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't happen. Other than that, being careful to not repeat content in a script/css bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name to prefix all urls in production mode. you can do all your development using your local files, then deploy to production and point them to a CDN automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included separately and uncompressed, so it's very easy to debug. Change a flag, and you get the packed version.
Q:Much more important than how far in the future the cache date is, what will the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle contents. It only changes when content does, so dont' worry, users get each script once and only once. And when a new version comes out, the URL changes so none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool i18n feature that generates javascript literals from resource bundle properties files.
You can get more ideas at the features list page at https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and roll your solution, best luck.
Regards to all,
Jordi.
was (Author: jordihs):
I'd love to see Jawr used by Tapestry, so I thought you might want more info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This means that you don't need to force users to learn how to use any new tool, but rather you can just use it behind the scenes.
There is some specific documentation on the subject at https://jawr.dev.java.net/integration/augmenter.html. You can get a general idea there, but integration possibilities go beyond what is explained there. For instance, the tag library delegates in tag-agnostic renderers. I made a JSF tag library out of these and each tag takes is almost a one-liner. I'm willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not modified) header and empty response body when if-modified-since or if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't happen. Other than that, being careful to not repeat content in a script/css bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name to prefix all urls in production mode. you can do all your development using your local files, then deploy to production and point them to a CDN automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included separately and uncompressed, so it's very easy to debug. Change a flag, and you get the packed version.
Q:Much more important than how far in the future the cache date is, what will the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle contents. It only changes when content does, so dont' worry, users get each script once and only once. And when a new version comes out, the URL changes so none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool i18n feature that generates javascript literals from resource bundle properties files.
You can get more ideas at the features list page at https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and roll your solution, best luck.
Regards to all,
Jordi.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1792) JavaScript libraries should be
automatically packed/minimalized
Posted by "Ernest Monklitch (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620195#action_12620195 ]
Ernest Monklitch commented on TAPESTRY-1792:
--------------------------------------------
Files bundled with Tapestry should be compressed at build time imho.
I personally don't want T5 to consume any precious cpu cycles compressing and concatenating files during runtime or consume memory caching those, as it can be easily achieved using build time tools. Hence, please make this configurable.
I recommed packing files bundled with T5 build time. There should be a configuration symbol to decide whether to use packed or non-packed files though (Both should be part of distribution.).
That, and add packing to be part of maven quick start should be enough.
I've used yui for my projects without single problem. (Although my js doesn't compare to dojo etc. at any level.)
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAPESTRY-1792
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1792
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Howard M. Lewis Ship
> Fix For: 5.1
>
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Jordi Hernandez Sellés (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660817#action_12660817 ]
Jordi Hernandez Sellés commented on TAP5-73:
--------------------------------------------
I'd love to see Jawr used by Tapestry, so I thought you might want more info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This means that you don't need to force users to learn how to use any new tool, but rather you can just use it behind the scenes.
There is some specific documentation on the subject at https://jawr.dev.java.net/integration/augmenter.html. You can get a general idea there, but integration possibilities go beyond what is explained there. For instance, the tag library delegates in tag-agnostic renderers. I made a JSF tag library out of these and each tag takes is almost a one-liner. I'm willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not modified) header and empty response body when if-modified-since or if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't happen. Other than that, being careful to not repeat content in a script/css bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name to prefix all urls in production mode. you can do all your development using your local files, then deploy to production and point them to a CDN automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included separately and uncompressed, so it's very easy to debug. Change a flag, and you get the packed version.
Q:Much more important than how far in the future the cache date is, what will the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle contents. It only changes when content does, so dont' worry, users get each script once and only once. And when a new version comes out, the URL changes so none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool i18n feature that generates javascript literals from resource bundle properties files.
You can get more ideas at the features list page at https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and roll your solution, best luck.
Regards to all,
Jordi.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1792) JavaScript libraries should be
automatically packed/minimalized
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAPESTRY-1792:
-------------------------------------------
Fix Version/s: 5.1
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAPESTRY-1792
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1792
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Howard M. Lewis Ship
> Fix For: 5.1
>
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Issue Comment Edited: (TAP5-73) JavaScript libraries should
be automatically packed/minimalized
Posted by "Jordi Hernandez Sellés (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660817#action_12660817 ]
jordihs edited comment on TAP5-73 at 1/5/09 9:03 AM:
--------------------------------------------------------------------
I'd love to see Jawr used by Tapestry, so I thought you might want more info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This means that you don't need to force users to learn how to use any new tool, but rather you can just use it behind the scenes.
There is some specific documentation on the subject at https://jawr.dev.java.net/integration/augmenter.html. You can get a general idea there, but integration possibilities go beyond what is explained there. For instance, the tag library delegates in tag-agnostic renderers. I made a facelets tag library out of these and each tag is almost a one-liner. I'm willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not modified) header and empty response body when if-modified-since or if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't happen. Other than that, being careful to not repeat content in a script/css bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name to prefix all urls in production mode. you can do all your development using your local files, then deploy to production and point them to a CDN automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included separately and uncompressed, so it's very easy to debug. Change a flag, and you get the packed version.
Q:Much more important than how far in the future the cache date is, what will the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle contents. It only changes when content does, so dont' worry, users get each script once and only once. And when a new version comes out, the URL changes so none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool i18n feature that generates javascript literals from resource bundle properties files.
You can get more ideas at the features list page at https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and roll your solution, best luck.
Regards to all,
Jordi.
was (Author: jordihs):
I'd love to see Jawr used by Tapestry, so I thought you might want more info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This means that you don't need to force users to learn how to use any new tool, but rather you can just use it behind the scenes.
There is some specific documentation on the subject at https://jawr.dev.java.net/integration/augmenter.html. You can get a general idea there, but integration possibilities go beyond what is explained there. For instance, the tag library delegates in tag-agnostic renderers. I made a JSF tag library out of these and each tag is almost a one-liner. I'm willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not modified) header and empty response body when if-modified-since or if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't happen. Other than that, being careful to not repeat content in a script/css bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows caching and could have a different bandwidth allowance (this is already a problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name to prefix all urls in production mode. you can do all your development using your local files, then deploy to production and point them to a CDN automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included separately and uncompressed, so it's very easy to debug. Change a flag, and you get the packed version.
Q:Much more important than how far in the future the cache date is, what will the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle contents. It only changes when content does, so dont' worry, users get each script once and only once. And when a new version comes out, the URL changes so none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool i18n feature that generates javascript literals from resource bundle properties files.
You can get more ideas at the features list page at https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and roll your solution, best luck.
Regards to all,
Jordi.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Andreas Andreou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645984#action_12645984 ]
Andreas Andreou commented on TAP5-73:
-------------------------------------
I'd suggest https://jawr.dev.java.net/
It does its work @ server startup and I guess it'd need a small service written for it in order to be usable from within
Tapestry, but i believe it has good potential...
Additionally, for ppl who want the same functionality at build time (like i did recently) there's a maven
plugin I did at http://github.com/andyhot/maven-jawr-plugin/
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-73:
-------------------------------------
Issue Type: New Feature (was: Bug)
The tricky part is determining which JS have been loaded on the client side, and only loading what is needed in a later Ajax update.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Martin Reurings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659442#action_12659442 ]
Martin Reurings commented on TAP5-73:
-------------------------------------
Much more important than how far in the future the cache date is, what will the uri of the resource be? If every page will have a unique uri for its' combined Javascripts the client will suddenly have to download prototype, scriptaculous and tapestry js-files for every page instead of just once for the entire application.
I suppose I'm just very paranoid about the possible pitfalls and I'll just have to see what you come up with :)
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-73) JavaScript libraries should be
automatically packed/minimalized
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659441#action_12659441 ]
Howard M. Lewis Ship commented on TAP5-73:
------------------------------------------
Like any other performance issue, it is necessary to measure.
I will be implementing this such that the level of packed/minimilzed & combined is controllable via a symbol contribution.
The packed/gzipped/combined JSs will have far future expiration dates which should help the client-side to cache.
My prediction is that a typical site will have very similar JS requirements page-to-page and will therefore see a net improvement here.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1792) JavaScript libraries should be
automatically packed/minimalized
Posted by "Martin Strand (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574063#action_12574063 ]
Martin Strand commented on TAPESTRY-1792:
-----------------------------------------
Yahoo's compressor works great, is very efficient, and can also compress css:
http://developer.yahoo.com/yui/compressor/
The js/css files bundled with Tapestry can be compressed at build time if you use this Maven plugin:
http://alchim.sourceforge.net/yuicompressor-maven-plugin/
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAPESTRY-1792
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1792
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Howard M. Lewis Ship
> Fix For: 5.1
>
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack" the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org