|
»
»
»
« Return to Thread: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users
Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users
by Jordi Hernandez
::
Rate this Message:
Hi Scott,
I looked at Trinidad and found out the scripts are inside a jar file. Jawr does not yet support reading js files off a jar so unless you extracted them to a dir in your war you would not be able to map them. reading from jar is planned for a future version though.
As for fragmenting or not the scripts, I'm not sure if I fully understand your point on granularity. Unless you are talking of seriously low level stuff, I guess by block you means separate requests, i.e. defining separate groups of files which are bundled together under one request. Jawr is all about doing that, so how blocks are served is up to you, you can configure as many bundles as you want very easily. An added benefit is that if the client supports it, gzipping will be used for much smaller file sizes.
That said, I think that while granularity should not be disregarded, the fact is that more separate requests end up making a single page load slower. Normally you'd want to join all your commonly used scripts, plus whichever libraries you use in a single file and load less commonly used stuff (large scripts you only use in a few pages or page-specific scripts) in separate bundles. The page I recommended in my original post and the performance tests by the yui team seem to suggest this.
I hope I'm not too pretentious by saying this, but maybe Trinidad should offer an option to let users load the scripts themselves. Not (just) for the sake of Jawr users, but think this: if a project uses several libraries that each import their own scripts at will, it might end up with pages which load say, 15 scripts. That can really be a big performance hit in page loading times...
Jawr also uses aggressive caching techniques (expires and etag headers, empty body response to if-modified-since head requests and urls that change only when a resource changes). So once a client has downloaded one of your bundles, it should stay cached.
Finally, I am not sure wether Jawr will work in a portlet application. You do need to add a servlet to the web app configuration which in my limited knowledge of the portlet technology means that it won't make any difference to its runtime. Same for JSPs, Jawr uses a standard JSP taglib so I guess it should work.
That said, I don't know if addinng a servlet alongside a portlet app is desirable or has unwanted side effects. Also, to load scripts using Jawr you need to use the taglib, meaning that pages for each portlet that require scripts to be loaded would need to be modified.
On the bright side, Jawr keeps track of which scripts were already loaded, so no duplicate script tags are generated (and these would cause an extra HTTP request, so that's a good thing to avoid).
Another nice thing is that, if portlet foo needs 'foo.js' and portlet bar needs 'bar.js', the Jawr tags can be explicit about it even if you have foo.js and bar.js joined in a bundle (i.e. foo.jsp has a tag pointing to 'foo.js', not some bundle name). Later, you remove the foo portlet from your app and add bar.js to a new, different bundle: no problem, it keeps working fine with no changes to the portlet.
My company uses Liferay for its internal portal. The main page loads 5 portlets which results in well over 20 js requests. Not counting the inlined javascript. Even from the intranet, it takes really long to load it. So I guess we could really benefit from using Jawr.
Ok, all that said, I have not tested Jawr with a portlet app yet. Do you know of a sample app that I could quickly deploy to Jetty or Tomcat to make some tests?
Regards,
Jordi.
I looked at Trinidad and found out the scripts are inside a jar file. Jawr does not yet support reading js files off a jar so unless you extracted them to a dir in your war you would not be able to map them. reading from jar is planned for a future version though.
As for fragmenting or not the scripts, I'm not sure if I fully understand your point on granularity. Unless you are talking of seriously low level stuff, I guess by block you means separate requests, i.e. defining separate groups of files which are bundled together under one request. Jawr is all about doing that, so how blocks are served is up to you, you can configure as many bundles as you want very easily. An added benefit is that if the client supports it, gzipping will be used for much smaller file sizes.
That said, I think that while granularity should not be disregarded, the fact is that more separate requests end up making a single page load slower. Normally you'd want to join all your commonly used scripts, plus whichever libraries you use in a single file and load less commonly used stuff (large scripts you only use in a few pages or page-specific scripts) in separate bundles. The page I recommended in my original post and the performance tests by the yui team seem to suggest this.
I hope I'm not too pretentious by saying this, but maybe Trinidad should offer an option to let users load the scripts themselves. Not (just) for the sake of Jawr users, but think this: if a project uses several libraries that each import their own scripts at will, it might end up with pages which load say, 15 scripts. That can really be a big performance hit in page loading times...
Jawr also uses aggressive caching techniques (expires and etag headers, empty body response to if-modified-since head requests and urls that change only when a resource changes). So once a client has downloaded one of your bundles, it should stay cached.
Finally, I am not sure wether Jawr will work in a portlet application. You do need to add a servlet to the web app configuration which in my limited knowledge of the portlet technology means that it won't make any difference to its runtime. Same for JSPs, Jawr uses a standard JSP taglib so I guess it should work.
That said, I don't know if addinng a servlet alongside a portlet app is desirable or has unwanted side effects. Also, to load scripts using Jawr you need to use the taglib, meaning that pages for each portlet that require scripts to be loaded would need to be modified.
On the bright side, Jawr keeps track of which scripts were already loaded, so no duplicate script tags are generated (and these would cause an extra HTTP request, so that's a good thing to avoid).
Another nice thing is that, if portlet foo needs 'foo.js' and portlet bar needs 'bar.js', the Jawr tags can be explicit about it even if you have foo.js and bar.js joined in a bundle (i.e. foo.jsp has a tag pointing to 'foo.js', not some bundle name). Later, you remove the foo portlet from your app and add bar.js to a new, different bundle: no problem, it keeps working fine with no changes to the portlet.
My company uses Liferay for its internal portal. The main page loads 5 portlets which results in well over 20 js requests. Not counting the inlined javascript. Even from the intranet, it takes really long to load it. So I guess we could really benefit from using Jawr.
Ok, all that said, I have not tested Jawr with a portlet app yet. Do you know of a sample app that I could quickly deploy to Jetty or Tomcat to make some tests?
Regards,
Jordi.
Scott O'Bryan wrote:The files do all exist in the jars, so it's possible you can configure
Jawr to do this if you wanted too. But currently there is no way to
have trinidad NOT link to the common js.
Truthfully though, Trinidad is pretty light on the javascript and
library segmentation (unless it's done intelligently) may actually cause
performance loss. Why? In the case of the Trinidad JS, once the
library is loaded, it's cached. This would mean that Jawr should not
simply aggregate the JS for components displayed, but would have to load
the library in well defined *blocks* so that they could be cached as
well. I have seen solutions like this work, and work very well, for
large javascript libraries provided things are loaded in blocks - the
real key is granularity.
Also, do you guys have any ideas if Jawr would work in a portlet
environment?
Scott
Renzo Tomaselli wrote:
> Looks really good.
> For Trinidad users - a rather obvious question: since Trinidad appears
> to do more or less the same - is there any chance to wire things so
> that single files (js and css) are rendered ?
> I know that Trinidad does merging on the fly - so that we are not
> allowed to configure Jawr with Trinidad files (such as
> /adf/jsLibs/Common1_0_7.js and the filtered out skin css file).
>
> -- Renzo
>
> Jordi Sellés wrote:
>> Hi to everyone on the list, this is my first posting announcing the
>> availability of a new Facelets related tool.
>>
>> Jawr <https:%5C%5Cjawr.dev.java.net> is an Open Source library which
>> offers two complementary uses for java and Facelets web applications
>> in which javascript is heavily used:
>>
>> * First, it's a productivity tool, since it allows to develop
>> javascript components in separate files, each representing a
>> module, as opposed to having all the code in one or two files
>> for performance reasons. Working with separate files makes
>> development, maintenance and version control a lot easier.
>>
>> * On the other hand, Jawr is a performance tool which will
>> perceivably improve page loading times. When in production
>> mode, all the modules which were split in separate files are
>> bundled together (into one or several files, as per
>> configuration), then minified, then compressed and sent to the
>> client using aggressive caching headers. This reduces the
>> number of HTTP requests required to load a full page and also
>> the size in kilobytes that a user must download. Jawr
>> implements many of the good practices defined in this very
>> interesting article which I recommend everyone to read: serving
>> javascript fast
>> <http://www.thinkvitamin.com/features/webapps/serving-javascript-fast>.
>>
>> Jawr is configured by adding a servlet to our application and
>> creating a simple .properties file to configure the way components
>> are to be bundled. CSS files can also benefit from bundling and
>> compression. Once configured, a Facelets tag library is used to
>> reference the bundles previously defined.
>>
>> These tags will work differently in development and production modes
>> (which are set by a flag in the properties file). When in development
>> mode, links to the separate, uncompressed modules are generated so
>> that we can debug them using, say, Firebug. Each links gets a random
>> parameter added to the URL so that upon every refresh of our page the
>> browser is force to reload the script. On the other hand, in
>> production mode links to the bundled, minified and compressed version
>> of the scripts are generated. There is no need to change anything in
>> the pages for this to happen, only a flag switch in the properties
>> file is needed.
>>
>> Other interesting features are traditional and Grails web apps
>> support, the ability to define custom postprocessors to change
>> dynamically the contents of bundled scripts, the ability to define
>> global bundles that are always imported into pages automatically,
>> defining bundles which are included within a defined conditional
>> comment for MSIE, obfuscating the scripts, etc...
>>
>> Jawr has an Apache 2.0 license, and can be configured to use JSmin or
>> the YUI Compressor under the hood, both with a BSD style license.
>> The full project documentation is at https:\\jawr.dev.java.net
>> <https:%5C%5Cjawr.dev.java.net>. You can find about the specifics for
>> using Jawr with Facelets here
>> <https://jawr.dev.java.net/docs/facelets.html>.
>>
>> regards,
>> Jordi Hernandez Selles
>>
>> ------------------------------------------------------------------------
>> Sigue de cerca las últimas tendencias y lo que más rompe MSN Vídeo
>> <http://video.msn.com/video.aspx?mkt=es-es>
« Return to Thread: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users
| Free Forum Powered by Nabble | Forum Help |