On Sun, Nov 29, 2009 at 09:14, Caleb James DeLisle <[email protected]> wrote: > Since there is no consensus on which optimizer (eg. jawr or wro4j) to use > I thought it would be a good idea to decide what is needed and compare > features. > > Some requirements: > 1. Creating bundles by calling an api (for "always used" document skin > extensions) > 2. Adding dynamic resources to bundles (eg: from jsx or skin actions) > 3. Calling a bundle from velocity. > Anything else?
I would add 4. Project life state and community size > > Feature comparison: > - Both jawr and wro4j support: > 1. Server side cache > 2. Browser/proxy caching - jawr uses "cache forever" > and creates different file after changes, wro4j uses a more > traditional method. > 3. Minification (only with wro4j-extensions) (jawr and wro4j both use YUI) > 4. Get resources from servlet context > (jawr) jawr.js.bundle.baz.mappings=/js/baz/**, /js/someScript.js, > /js/someSubdir/ > jawr uses ServletContext.getResourceAsStream > (wro4j) <css>/static/css/style.css</css> > 5. Get resources from classpath > (jawr) jawr.js.bundle.foo.mappings=jar:/com/mycompany/myapp/foo.js, > /js/bar.js > (wro4j) <css>classpath:ro/isdc/resources/file.css</css> > 7. gzip where request says it's supported by the browser > > - Only jawr supports: > 1. Creating and registering custom "generators" for getting scripts from > skinx objects, external URLs via http get, through "skin action" etc. > https://jawr.dev.java.net/docs/generators.html > 2. Interpreting css @import and replacing with imported document > 3. Logging (via log4j) > 4. Recursively loading by directory (not available when loading from > classpath) > info about order https://jawr.dev.java.net/docs/source_ordering.html > 5. supports i18n messages > https://jawr.dev.java.net/docs/messages_gen.html > 6. jawr is better documented > > - Only wro4j supports: > 1. Get resources from external url > <css>http://www.site.com/static/style.css</css> > 2. Get resources from local file (not in servlet WEB-INF/) > <css>file:c:/temp/file.css</css> > * These could be replicated with custom generators. > 3. css variables (named colors etc.) > 4. wro4j is much simpler > > Some reading: > http://code.google.com/p/wro4j/wiki/GettingStarted > http://code.google.com/p/wro4j/wiki/Features > > https://jawr.dev.java.net/files/documents/8162/135874/jawr-2.8-docs.zip > https://jawr.dev.java.net/servlets/ProjectMailingListList > https://jawr.dev.java.net/servlets/ForumMessageList?forumID=3025 > > In the end it seems to be a matter of opinion. > In my opinion jawr is best because of the sendmail effect, the bigger the mess > the less likely that some feature we need will be missing. > > Any thoughts? > > > Caleb James DeLisle > > > Jerome Velociter wrote: >> On 11/10/09 11:06 AM, Jerome Velociter wrote: >>> On 11/10/09 10:41 AM, Pascal Voitot wrote: >>>> On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol<[email protected]> >>>> wrote: >>>> >>>>> On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote: >>>>> >>>>>> Have you seen my mail about JAWR which is exactly this : >>>>>> "On the other hand wro4j allows you to organize your resources in >>>>>> groups >>>>>> and supports gzip compression." >>>>>> >>>>>> if you need JS optimization, I think Google Closure Compiler is the >>>>>> way to >>>>>> look at... With chrome and all the work they do around JS, they are >>>>>> certainly the ones to follow just now :) >>>>> We're already minifying our JS both at build time and at runtime >>>>> (although we could switch to Google Closure at some point in the >>>>> future if it's better). >>>>> >>>>> >>>> apparently it's really efficient but I'm not a JS expert enough to consider >>>> its real power... >>> I really think compressing / compiling together JS is for us the tip of >>> an iceberg in terms of JS optimization. >>> >>> As I said previously on this thread, we can't do that for JavaScript >>> extensions which are loaded conditionally in a non-predictable manner. >>> They represent more than half the JS files we load on the home page >>> today for example. >>> >>> Note that we should find a way in the JSFX to declare an extension being >>> "loaded on all pages" (it's not possible yet), so that extensions such >>> as jump to page and other common widgets can be aggregated with other >>> "always served" JS. >>> >>> But even if we do that, remains all the extensions added on demand >>> (there are some on the home page, too) that can be solved but by an >>> asynchronous script loading mechanism (see >>> http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ for >>> example). >> >> A candidate library to implement this would be >> http://developer.yahoo.com/yui/get/ >> >> Jerome. >>> My 2 cents, >>> Jerome. >>>> >>>>> But I don't think Google Closure will merge CSS and JS files together. >>>>> >>>>> >>>> no i don't think so :) >>>> >>>> >>>>> Re JAWR indeed we've already mentioned it several times on >>>>> http://jira.xwiki.org/jira/browse/XWIKI-2022 >>>>> (the lead dev for it has even commented in that issue!). We should >>>>> definitely evaluate it vs wro4j. >>>>> >>>>> >>>> don't know wro4j... should have a look at it, just to know! >>>> >>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> regards >>>>>> Pascal >>>>>> >>>>>> >>>>>> On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea< >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Vincent, >>>>>>> >>>>>>> Vincent Massol wrote: >>>>>>>> On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote: >>>>>>>> >>>>>>>>> Hi Marius, >>>>>>>>> >>>>>>>>> On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote: >>>>>>>>> >>>>>>>>>> Jerome Velociter wrote: >>>>>>>>>>> Hi Thibaul, all >>>>>>>>>>> >>>>>>>>>>> Something easy to do that would contribute to reduce the number >>>>>>>>>>> of >>>>>>>>>>> CSS >>>>>>>>>>> files is to concatenate all the WYSIWYG CSS files from the >>>>>>>>>>> various >>>>>>>>>>> plugins at build time (there are more than 10 AFAIK). Marius, >>>>>>>>>>> have >>>>>>>>>>> you >>>>>>>>>>> looked into this? Do you know if this could be done in the 2.1 >>>>>>>>>>> timeframe ? >>>>>>>>>> There are I think three steps to be taken in order to minimize the >>>>>>>>>> CSS load: >>>>>>>>>> >>>>>>>>>> 1) expand @import url('someURL'); >>>>>>>>>> 2) concatenate CSS files >>>>>>>>>> 3) minify the resulted CSS file >>>>>>>>>> >>>>>>>>>> So far I haven't found a tool to expand the CSS import >>>>>>>>>> declaration. >>>>>>>>>> Maybe I could write a small maven plugin for this. >>>>>>>>> I've found this: >>>>>>>>> http://raibledesigns.com/rd/entry/javascript_and_css_concatenation >>>>>>>>> >>>>>>>>> which leads to wro4j: http://code.google.com/p/wro4j/ >>>>>>> wro4j seems to be a runtime optimizer while YUI Compressor is a build >>>>>>> time optimizer. I'm not sure which approach is the best. On the maven >>>>>>> YUI Compressor site they say: >>>>>>> >>>>>>> "Because Javascript compression could need time and resource, and to >>>>>>> avoid repetitive (stupid) resources consumming at runtime, this >>>>>>> plugin >>>>>>> do compression of static files at compile time." >>>>>>> >>>>>>> On the other hand wro4j allows you to organize your resources in >>>>>>> groups >>>>>>> and supports gzip compression. >>>>>>> >>>>>>>> hmmm.... >>>>>>>> http://code.google.com/p/wro4j/wiki/KnownIssues >>>>>>> I'll drop the @import declarations and merge the CSS files instead. >>>>>>> >>>>>>> Thanks, >>>>>>> Marius >>>>>>> >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Sounds promising. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>>> I think we can adapt to maven what is presented in this article >>>>>>>>>> >>>>> http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/ >>>>>>>>>> in order to achieve the last two steps. >>>>>>>>>> >>>>>>>>>> Marius >>>>>>>>>> >>>>>>>>>>> Note that the target of 1 CSS and 1 JS is pretty challenging for >>>>>>>>>>> XWiki >>>>>>>>>>> as we are also making it a modular software where CSS and JS >>>>>>>>>>> extensions >>>>>>>>>>> can be conditionally loaded on some (not all) of the pages. >>>>>>>>>>> Something to >>>>>>>>>>> investigate for JavaScript extensions could be a dynamic JS >>>>>>>>>>> loading >>>>>>>>>>> mecanism, a la dojo >>>>>>>>>>> ( >>>>> http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/ >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> Jerome. >>>>>>>>>>> >>>>>>>>>>> PS: I put devs in copy as this is more a developer topic. >>>>>>>>>>> >>>>>>>>>>> On 11/5/09 5:28 PM, Thibaut Camberlin wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Page Loading time is a very important criteria when developing a >>>>>>>>>>>> web site. >>>>>>>>>>>> According to a recent >>>>>>>>>>>> survey< >>>>> http://www.webdesignerwall.com/general/users-place-more-weight-on-design/ >>>>>>>>>>>>> more >>>>>>>>>>>> than half people would drive away from a site with slow loading >>>>>>>>>>>> pages. >>>>>>>>>>>> >>>>>>>>>>>> There are several interesting issues that could be implemented >>>>>>>>>>>> to >>>>>>>>>>>> substantially improve page loading time in XWiki. >>>>>>>>>>>> >>>>>>>>>>>> Number one is aggreation of CSS and JS files in order to reduce >>>>>>>>>>>> HTTP >>>>>>>>>>>> requests. (For info, we have a total of 25 external CSS and JS >>>>>>>>>>>> files on a >>>>>>>>>>>> basic XWiki install when in the best world we would have just >>>>>>>>>>>> 2 - >>>>>>>>>>>> 1 CSS and >>>>>>>>>>>> 1 JS) >>>>>>>>>>>> >>>>>>>>>>>> Someone interrested in working on this with me ? >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
