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