[jira] Commented: (TAP5-73) JavaScript libraries should be automatically packed/minimalized

["Joshua Long (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717165#action_12717165 ] 

Joshua Long commented on TAP5-73:
---------------------------------

I'm pleased that some of these changes came through in Tapestry 5.1, but it seems like it's not quite enough to fill the gap. For me the goal is to make the YSlow plugin and the Google Page Speed plugin absolutely just purr on the pages I create.  I understand the dynamic behavior of Tapestry does complicate things a little, but I think its surmountable. And, in fact, Tapestry's already halfway there. 

The way JAWR works is that on application startup time, it looks in different directories and creates a cached minified asset for all the bundles/js/css it finds. These various artifacts are never recreated. With Tapestry, this is slightly more complicated because you don't really have an efficient way of resolving all the JavaScript files since Tapestry's kind/smart enough to load from the classpath at runtime. Even if you think about applying this technique to all js files that are registered via @IncludeJavaScript, you then have to worry about the dynamically added JS from the renderSupport and so on. Several different solutions come to mind:
   - could tapestry also support the notion of a JAWR bundle in the @IncludeJavaScript annotation? These bundles would be arbitrary names. Heck, since theyre just names, those bundles might be overridable by clients too using TapestryIOC or something. This would be another way to solve the issue of having to "undo" the Tapestry default CSS or Client side validation: just override / replace the bundle. in your own specific JAWR configuration.
  -  if a resource is so important, surely its not too much to ask the user to enumerate them as bundles? 

Perhaps there be several 'layers' of support. Debug would be: just write out each and every css/js file. production defaults would be: all Tapestry shipped CSS/JS code is minified/compressed using JAWR, but userland components dont benefit from it unless they opt in. Opting in mean having components use the idea of a bundle instead of a regular js file. Additionally, JAWR is smart enough to intercept requests for standard JS links and return the minified version instead. This would mean 3rd party components that don't use the bundle structure but that do use CSS/JS could still have their assets compressed using this system. For those components that Tapestry doesn't know about at startup time (for example, in a third party component that loads the js at runtime), perhaps there could be a setting to, on the fly, cache/minify/gzip these files and then return subsequent requests for them with the cached version? This, also would be opt-in. I dont know at what granularity this mechanism is supported. The above posts mention the concern of tapestry creating a separate js/css bundle that forces the redownload of prototype/blackbird/etc on each page, and i agree thats valid. So perhaps if the user has opted in, but the js is in a third party component thats not using a bundle name, then for those js files (not the sum collection of js from that component, but for each individual one) we just return the js/css file minified/compressed but dont serve up all the js/css as a group. 

Put another way, my ideal setup, assuming ive enabled every optimisation Tapestry provides: 
 - My code and any third party components deal in bundle names, which means that a third party component may load 10 js files, but I only pay the price of loading one gzipped/minified file for the component. Code using bundles would benefit from one-time compilation of the bundles at startup via a JAWR-like config option for tapestry. 
 - Any code that doesnt deal in terms of bundles is still gzipped, minified, but it manifests as as many includes as required, ie: i'd still have 10 js script tags, but theyre individually packed.  code using explicit js/css references would be served up dynamically, but all subsequent, like requests would be served from the cached version. 

Personally, I like the idea of an opt-in system with tapestry stuff JAWR'd by default and then, in my pages/components, I have the ability to pass bundle names around to the createScriptLink and @IncludeJavaScript annotations. I don't use third party components (not yet, anyway) but just being able to consolidate /gzip all MY stuff (5 js files and 6 css files, one of each of which is designed to undo the Tapestry defaults) would be a huge win. 

All of this is meant to be equally applicable to CSS as well as JS, since CSS is as integral a part of a components 'package' as JS, in my view. This is part and parcel with why I love Tapestry: the ability to componentize common look and feels, behaviors and so on helps me scale the site out. Being able to carry forward the CSS is vital. 





> 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.