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